राम्रो-फेड दार्शनिक वा प्रतिस्पर्धी .NET प्रोग्रामिंग

.Net मा समवर्ती र समानान्तर प्रोग्रामिङले कसरी काम गर्छ हेरौं, उदाहरणको रूपमा Philosophers Dining Problem प्रयोग गरेर। योजना यो हो, थ्रेडहरू / प्रक्रियाहरूको सिंक्रोनाइजेसनबाट, अभिनेता मोडेलमा (निम्न भागहरूमा)। लेख पहिलो परिचितको लागि वा तपाईंको ज्ञान ताजा गर्नको लागि उपयोगी हुन सक्छ।

आखिर किन गर्ने ? ट्रान्जिस्टरहरू तिनीहरूको न्यूनतम आकारमा पुग्छन्, मूरको नियम प्रकाशको गतिको सीमिततामा आधारित छ र त्यसैले संख्यामा वृद्धि देखाइएको छ, थप ट्रान्जिस्टरहरू बनाउन सकिन्छ। एकै समयमा, डाटाको मात्रा बढ्दै छ, र प्रयोगकर्ताहरूले प्रणालीबाट तत्काल प्रतिक्रियाको अपेक्षा गर्छन्। यस्तो अवस्थामा, "सामान्य" प्रोग्रामिङ, जब हामीसँग एक कार्यान्वयन थ्रेड हुन्छ, अब प्रभावकारी हुँदैन। तपाईंले कुनै न कुनै रूपमा एक साथ वा समवर्ती कार्यान्वयनको समस्या समाधान गर्न आवश्यक छ। यसबाहेक, यो समस्या विभिन्न स्तरहरूमा अवस्थित छ: थ्रेड को स्तर मा, प्रक्रिया को स्तर मा, नेटवर्क मा मिसिन को स्तर मा (वितरण प्रणाली)। .NET सँग छिट्टै र प्रभावकारी रूपमा यस्ता समस्याहरू समाधान गर्न उच्च गुणस्तरीय, समय-परीक्षण प्रविधिहरू छन्।

उद्देश्य

Edsger Dijkstra ले 1965 को शुरुमा नै आफ्ना विद्यार्थीहरूलाई यो समस्या खडा गरे। स्थापना गरिएको सूत्र निम्नानुसार छ। त्यहाँ निश्चित (सामान्यतया पाँच) दार्शनिकहरूको संख्या र काँटाहरूको उही संख्या छ। तिनीहरू एक गोल टेबलमा बस्छन्, तिनीहरूको बीचमा काँटाहरू। दार्शनिकहरूले अनन्त खानाको प्लेटबाट खान सक्छन्, सोच्न वा पर्खन सक्छन्। दार्शनिक खानको लागि, तपाईंले दुई काँटा लिनु पर्छ (अन्तिमले पहिलोसँग काँटा साझा गर्दछ)। फोर्क उठाउनु र तल राख्नु दुई फरक कार्यहरू हुन्। सबै दार्शनिकहरू मौन छन्। काम भनेको यस्तो एल्गोरिथ्म खोज्नु हो कि सबैले सोच्ने र 54 वर्ष पछि पनि पूर्ण हुनेछ।

पहिले, साझा स्थान को उपयोग मार्फत यो समस्या समाधान गर्न प्रयास गरौं। काँटाहरू साझा टेबलमा पल्टिन्छन् र दार्शनिकहरूले तिनीहरू हुँदा मात्र लैजान्छन् र फिर्ता राख्छन्। यहाँ सिंक्रोनाइजेसनको साथ समस्याहरू छन्, निश्चित रूपमा कहिले लिने? काँटा छैन भने के हुन्छ? आदि। तर पहिले, दार्शनिकहरू सुरु गरौं।

थ्रेडहरू सुरु गर्न, हामी थ्रेड पूल प्रयोग गर्छौं Task.Run विधि:

var cancelTokenSource = new CancellationTokenSource();
Action<int> create = (i) => RunPhilosopher(i, cancelTokenSource.Token);
for (int i = 0; i < philosophersAmount; i++) 
{
    int icopy = i;
    // Поместить задачу в очередь пула потоков. Метод RunDeadlock не запускаеться 
    // сразу, а ждет своего потока. Асинхронный запуск.
    philosophers[i] = Task.Run(() => create(icopy), cancelTokenSource.Token);
}

थ्रेड पूल थ्रेड निर्माण र मेटाउने अनुकूलन गर्न डिजाइन गरिएको छ। यो पोखरीमा कार्यहरू सहितको लाम छ र CLR ले यी कार्यहरूको सङ्ख्याको आधारमा थ्रेडहरू सिर्जना वा हटाउँछ। सबै AppDomains को लागि एक पूल। यो पोखरी लगभग सधैं प्रयोग गर्नुपर्छ, किनभने। थ्रेडहरू, तिनीहरूको लामहरू, आदि सिर्जना गर्न, मेटाउनको लागि चिन्ता लिनु पर्दैन। यो पूल बिना सम्भव छ, तर तपाईंले यसलाई सीधा प्रयोग गर्नुपर्नेछ। Thread, यो केसहरूको लागि उपयोगी छ जब तपाइँ थ्रेडको प्राथमिकता परिवर्तन गर्न आवश्यक छ, जब हामीसँग लामो सञ्चालन हुन्छ, अग्रभूमि थ्रेडको लागि, आदि।

अर्को शब्दमा, System.Threading.Tasks.Task कक्षा एउटै छ Thread, तर सबै प्रकारका सुविधाहरूसँग: अन्य कार्यहरूको ब्लक पछि कार्य चलाउने क्षमता, तिनीहरूलाई कार्यहरूबाट फर्काउने, तिनीहरूलाई सहज रूपमा अवरोध गर्ने, र थप। इत्यादि। तिनीहरू async / पर्खाइ निर्माणहरूलाई समर्थन गर्न आवश्यक छ (कार्य-आधारित एसिन्क्रोनस ढाँचा, IO अपरेशनहरूको लागि पर्खनका लागि सिन्ट्याक्टिक चिनी)। हामी यस बारे पछि कुरा गर्नेछौं।

CancelationTokenSource यहाँ यो आवश्यक छ कि थ्रेडले कलिङ थ्रेडको संकेतमा आफैलाई समाप्त गर्न सक्छ।

सिंक समस्याहरू

अवरुद्ध दार्शनिकहरू

ठीक छ, हामीलाई थ्रेडहरू कसरी बनाउने भनेर थाहा छ, लंच खाने प्रयास गरौं:

// Кто какие вилки взял. К примеру: 1 1 3 3 - 1й и 3й взяли первые две пары.
private int[] forks = Enumerable.Repeat(0, philosophersAmount).ToArray();

// То же, что RunPhilosopher()
private void RunDeadlock(int i, CancellationToken token) 
{
    // Ждать вилку, взять её. Эквивалентно: 
    // while(true) 
    //     if forks[fork] == 0 
    //          forks[fork] = i+1
    //          break
    //     Thread.Sleep() или Yield() или SpinWait()
    void TakeFork(int fork) =>
        SpinWait.SpinUntil(() => 
            Interlocked.CompareExchange(ref forks[fork], i+1, 0) == 0);

    // Для простоты, но можно с Interlocked.Exchange:
    void PutFork(int fork) => forks[fork] = 0;

    while (true)
    {
        TakeFork(Left(i));
        TakeFork(Right(i));
        eatenFood[i] = (eatenFood[i] + 1) % (int.MaxValue - 1);
        PutFork(Left(i));
        PutFork(Right(i));
        Think(i);

        // Завершить работу по-хорошему.
        token.ThrowIfCancellationRequested();
    }
}

यहाँ हामी पहिले बायाँ काँटा, र त्यसपछि दायाँ काँटा लिन कोशिस गर्छौं, र यदि यसले काम गर्छ भने, हामी खान्छौं र फिर्ता राख्छौं। एउटा काँटा लिनु परमाणु हो, अर्थात् दुई थ्रेडहरूले एकै समयमा एउटा लिन सक्दैन (गलत: पहिलोले फोर्क नि: शुल्क छ भनेर पढ्छ, दोस्रो - पनि, पहिलोले लिन्छ, दोस्रोले लिन्छ)। यसका लागि Interlocked.CompareExchange, जुन प्रोसेसर निर्देशनको साथ लागू गरिनु पर्छ (TSL, XCHG), जसले परमाणु अनुक्रमिक पढाइ र लेखनको लागि मेमोरीको टुक्रा लक गर्दछ। र स्पिनवेट निर्माणको बराबर छ while(true) केवल थोरै "जादू" संग - थ्रेडले प्रोसेसर लिन्छ (Thread.SpinWait), तर कहिले काहिँ अर्को थ्रेडमा नियन्त्रण स्थानान्तरण गर्दछ (Thread.Yeild) वा सुत्छ (Thread.Sleep).

तर यो समाधान काम गर्दैन, किनभने प्रवाहहरू चाँडै (मेरो लागि एक सेकेन्ड भित्र) अवरुद्ध हुन्छन्: सबै दार्शनिकहरूले आफ्नो बायाँ काँटा लिन्छन्, तर दायाँ होइन। फोर्क एरेमा त्यसपछि मानहरू छन्: 1 2 3 4 5।

चित्रमा, थ्रेडहरू अवरुद्ध गर्दै (डेडलक)। हरियो - कार्यान्वयन, रातो - सिंक्रोनाइजेसन, खैरो - थ्रेड सुतिरहेको छ। रोम्बसहरूले कार्यको सुरु हुने समयलाई संकेत गर्दछ।

दार्शनिकहरूको भोक

यद्यपि यो विशेष गरी खाना धेरै सोच्न आवश्यक छैन, तर भोकले जो कोहीलाई दर्शन त्याग्न बनाउँछ। हाम्रो समस्यामा थ्रेडको भोकमरीको अवस्था अनुकरण गर्ने प्रयास गरौं। भोकमरी भनेको थ्रेड चलिरहेको बेला हो, तर महत्त्वपूर्ण काम बिना, अर्को शब्दमा, यो उस्तै गतिरोध हो, केवल अब धागो सुतिरहेको छैन, तर सक्रिय रूपमा केहि खानेकुरा खोजिरहेको छ, तर त्यहाँ कुनै खाना छैन। बारम्बार अवरुद्ध हुनबाट जोगिनको लागि, यदि हामीले अर्को लिन सकेनौं भने हामी फोर्क फिर्ता राख्नेछौं।

// То же что и в RunDeadlock, но теперь кладем вилку назад и добавляем плохих философов.
private void RunStarvation(int i, CancellationToken token)
{
    while (true)
    {
        bool hasTwoForks = false;
        var waitTime = TimeSpan.FromMilliseconds(50);
        // Плохой философов может уже иметь вилку:
        bool hasLeft = forks[Left(i)] == i + 1;
        if (hasLeft || TakeFork(Left(i), i + 1, waitTime))
        {
            if (TakeFork(Right(i), i + 1, TimeSpan.Zero))
                hasTwoForks = true;
            else
                PutFork(Left(i)); // Иногда плохой философ отдает вилку назад.
        } 
        if (!hasTwoForks)
        {
            if (token.IsCancellationRequested) break;
            continue;
        }
        eatenFood[i] = (eatenFood[i] + 1) % (int.MaxValue - 1);
        bool goodPhilosopher = i % 2 == 0;
        // А плохой философ забывает положить свою вилку обратно:
        if (goodPhilosopher)
            PutFork(Left(i));
        // А если и правую не положит, то хорошие будут вообще без еды.
        PutFork(Right(i));

        Think(i);

        if (token.IsCancellationRequested)
            break;
    }
}

// Теперь можно ждать определенное время.
bool TakeFork(int fork, int philosopher, TimeSpan? waitTime = null)
{
    return SpinWait.SpinUntil(
        () => Interlocked.CompareExchange(ref forks[fork], philosopher, 0) == 0,
              waitTime ?? TimeSpan.FromMilliseconds(-1)
    );
}

यस कोडको महत्त्वपूर्ण कुरा यो हो कि चार मध्ये दुई दार्शनिकहरूले आफ्नो बायाँ काँटा तल राख्न बिर्सन्छन्। र यो बाहिर जान्छ कि तिनीहरूले धेरै खाना खान्छन्, जबकि अरूहरू भोकाउन थाल्छन्, यद्यपि थ्रेडहरूको समान प्राथमिकता छ। यहाँ तिनीहरू पूर्ण रूपमा भोकै छैनन्, किनभने। खराब दार्शनिकहरूले कहिलेकाहीँ आफ्नो काँटा फिर्ता राख्छन्। राम्रो मान्छेले नराम्रो भन्दा ५ गुणा कम खाने कुरा पत्ता लाग्यो। त्यसैले कोडमा सानो त्रुटिले प्रदर्शनमा गिरावट ल्याउँछ। यहाँ यो पनि ध्यान दिन लायक छ कि एक दुर्लभ अवस्था सम्भव छ जब सबै दार्शनिकहरूले बायाँ काँटा लिन्छन्, त्यहाँ दायाँ कोही छैन, उनीहरूले बाँया राख्छन्, पर्खनुहोस्, फेरि बाँया लिनुहोस्, आदि। यो अवस्था पनि एक भोकमरी हो, एक गतिरोध जस्तै। म यसलाई दोहोर्याउन असफल भएँ। तल एक अवस्थाको लागि चित्र छ जहाँ दुई खराब दार्शनिकहरूले दुवै काँटा लिएका छन् र दुई राम्राहरू भोकै छन्।

यहाँ तपाईंले देख्न सक्नुहुन्छ कि थ्रेडहरू कहिलेकाहीँ उठ्छन् र स्रोत प्राप्त गर्ने प्रयास गर्छन्। चार कोर मध्ये दुईले केही गर्दैनन् (माथिको हरियो ग्राफ)।

एक दार्शनिक को मृत्यु

खैर, अर्को समस्या जसले दार्शनिकहरूको गौरवशाली रात्रिभोजमा बाधा पुर्‍याउन सक्छ यदि तिनीहरू मध्ये एक अचानक हातमा काँटा लिएर मर्यो (र उनीहरूले उसलाई त्यसरी गाड्नेछन्)। त्यसपछि छिमेकीहरू रातको खाना बिना छोडिनेछन्। तपाईं यस केसको लागि उदाहरण कोडको साथ आउन सक्नुहुन्छ, उदाहरणका लागि, यो बाहिर फ्याँकिएको छ NullReferenceException दार्शनिकले काँटा लिए पछि। र, वैसे, अपवाद ह्यान्डल गरिने छैन र कलिङ कोडले मात्र यसलाई समात्दैन (यसको लागि AppDomain.CurrentDomain.UnhandledException र आदि)। त्यसकारण, त्रुटि ह्यान्डलरहरू थ्रेडहरू आफैंमा र आकर्षक समाप्तिको साथ आवश्यक छ।

भट्टर

ठीक छ, हामी यो गतिरोध, भोकमरी र मृत्युको समस्या कसरी समाधान गर्ने? हामी केवल एक दार्शनिकलाई फोर्कमा पुग्न अनुमति दिनेछौं, यस ठाउँको लागि थ्रेडहरूको पारस्परिक बहिष्कार थप्नुहोस्। यो कसरी गर्ने? मानौं दार्शनिकहरूको छेउमा एउटा वेटर छ जसले कुनै एक दार्शनिकलाई काँटा लिन अनुमति दिन्छ। यो वेटरलाई कसरी बनाउने र दार्शनिकहरूले उनलाई कसरी सोध्ने, प्रश्नहरू रोचक छन्।

दार्शनिकहरूले काँटाहरूमा पहुँचको लागि वेटरलाई निरन्तर सोध्ने सबैभन्दा सरल तरिका हो। ती। अब दार्शनिकहरूले नजिकैको काँटाको लागि पर्खने छैनन्, तर पर्खनुहोस् वा वेटरलाई सोध्नुहोस्। सुरुमा, हामी यसको लागि प्रयोगकर्ता स्पेस मात्र प्रयोग गर्छौं, यसमा हामी कर्नेलबाट कुनै पनि प्रक्रियाहरू कल गर्न अवरोधहरू प्रयोग गर्दैनौं (तलको बारेमा)।

प्रयोगकर्ता अन्तरिक्ष मा समाधान

यहाँ हामीले एउटा काँटा र दुई दार्शनिकले गरे जस्तै गर्नेछौं, हामी चक्रमा घुम्नेछौं र पर्खनेछौं। तर अब यो सबै दार्शनिकहरू हुनेछन् र, जस्तै, केवल एक काँटा, अर्थात्। यो भन्न सकिन्छ कि वेटरबाट यो "सुन काँटा" लिने दार्शनिकले मात्र खानेछ। यसको लागि हामी SpinLock प्रयोग गर्छौं।

private static SpinLock spinLock = new SpinLock();  // Наш "официант"
private void RunSpinLock(int i, CancellationToken token)
{
    while (true)
    {
        // Взаимная блокировка через busy waiting. Вызываем до try, чтобы
        // выбрасить исключение в случае ошибки в самом SpinLock.
        bool hasLock = false;
        spinLock.Enter(ref hasLock);
        try
        {
            // Здесь может быть только один поток (mutual exclusion).
            forks[Left(i)] = i + 1;  // Берем вилку сразу, без ожидания.
            forks[Right(i)] = i + 1;
            eatenFood[i] = (eatenFood[i] + 1) % (int.MaxValue - 1);
            forks[Left(i)] = 0;
            forks[Right(i)] = 0;
        }
        finally
        {
            if(hasLock) spinLock.Exit();  // Избегаем проблемы со смертью философа.
        }

        Think(i);

        if (token.IsCancellationRequested)
            break;
    }
}

SpinLock यो एक अवरोधक हो, संग, लगभग बोल्दै, समान while(true) { if (!lock) break; }, तर भित्र भन्दा पनि धेरै "जादू" संग SpinWait (जुन त्यहाँ प्रयोग गरिन्छ)। अब उसले पर्खनेहरूलाई कसरी गणना गर्ने, तिनीहरूलाई थोरै सुत्ने र थप कुराहरू कसरी गर्ने भनेर जान्दछन्। आदि। सामान्यतया, अनुकूलन गर्न सम्भव सबै गर्छ। तर हामीले यो सम्झनुपर्छ कि यो अझै पनि उही सक्रिय चक्र हो जसले प्रोसेसर स्रोतहरू खान्छ र प्रवाहलाई राख्छ, जसले भोकमरी निम्त्याउन सक्छ यदि दार्शनिकहरू मध्ये एक अरू भन्दा बढी प्राथमिकतामा हुन्छ, तर सुनको काँटा छैन (प्राथमिकता उल्टो समस्या)। । त्यसकारण, हामी यसलाई कुनै पनि तेस्रो-पक्ष कलहरू, नेस्टेड लकहरू, र अन्य आश्चर्यहरू बिना साझा मेमोरीमा धेरै छोटो परिवर्तनहरूको लागि मात्र प्रयोग गर्छौं।

को लागी रेखाचित्र SpinLock। स्ट्रिमहरू सुनौलो काँटाको लागि निरन्तर "लडाइँ" छन्। त्यहाँ विफलताहरू छन् - चित्रमा, चयन गरिएको क्षेत्र। कोरहरू पूर्ण रूपमा प्रयोग गरिएका छैनन्: यी चार थ्रेडहरूद्वारा मात्र 2/3।

अर्को समाधान यहाँ प्रयोग गर्न मात्र हुनेछ Interlocked.CompareExchange माथिको कोडमा देखाइए जस्तै सक्रिय पर्खाइको साथ (भोकले मरेका दार्शनिकहरूमा), तर यो, पहिले नै भनिएझैं, सैद्धान्तिक रूपमा अवरुद्ध हुन सक्छ।

बारेमा Interlocked यो ध्यान दिनुपर्छ कि त्यहाँ मात्र छैन CompareExchange, तर परमाणु पढ्न र लेख्नका लागि अन्य विधिहरू पनि। र परिवर्तनको पुनरावृत्ति मार्फत, यदि अर्को थ्रेडमा परिवर्तनहरू गर्न समय छ भने (पढ्नुहोस् 1, पढ्नुहोस् 2, लेख्नुहोस् 2, लेख्नुहोस् 1 खराब छ), यसलाई एकल मानमा जटिल परिवर्तनहरूको लागि प्रयोग गर्न सकिन्छ (इन्टरलक गरिएको कुनै पनि ढाँचा)। ।

कर्नेल मोड समाधान

लूपमा स्रोतहरू बर्बाद हुनबाट जोगिन, हामी कसरी थ्रेड ब्लक गर्न सक्छौं हेरौं। अर्को शब्दमा, हाम्रो उदाहरण जारी राख्दै, हेरौं कि कसरी वेटरले दार्शनिकलाई सुत्छ र आवश्यक पर्दा मात्र उसलाई उठाउँछ। पहिले, अपरेटिङ सिस्टमको कर्नेल मोड मार्फत यो कसरी गर्ने भनेर हेरौं। त्यहाँ सबै संरचनाहरू प्रायः प्रयोगकर्ता स्पेसमा भएका संरचनाहरू भन्दा ढिलो हुन्छन्। उदाहरणका लागि, धेरै पटक ढिलो AutoResetEvent सायद ५३ गुणा ढिलो SpinLock [रिक्टर]। तर तिनीहरूको मद्दतले, तपाइँ प्रणालीमा प्रक्रियाहरू सिङ्क्रोनाइज गर्न सक्नुहुन्छ, व्यवस्थित वा होइन।

यहाँको आधारभूत निर्माण आधा शताब्दी अघि डिज्कस्ट्राले प्रस्ताव गरेको सेमाफोर हो। सेमाफोर भनेको प्रणालीद्वारा व्यवस्थित गरिएको सकारात्मक पूर्णांक हो, र यसमा दुईवटा अपरेशनहरू वृद्धि र घटाइ हुन्छ। यदि यो घटाउन असफल भयो भने, शून्य, त्यसपछि कलिङ थ्रेड अवरुद्ध छ। जब संख्या केही अन्य सक्रिय थ्रेड/प्रक्रियाद्वारा बढाइन्छ, तब थ्रेडहरू छोडिन्छन् र सेमाफोर फेरि पास गरिएको संख्याद्वारा घटाइन्छ। एक सेमाफोर संग एक बाधा मा ट्रेन को कल्पना गर्न सक्नुहुन्छ। .NET ले समान कार्यक्षमताका साथ धेरै निर्माणहरू प्रदान गर्दछ: AutoResetEvent, ManualResetEvent, Mutex र म Semaphore। हामी प्रयोग गर्नेछौं AutoResetEvent, यो यी निर्माणहरू मध्ये सरल छ: केवल दुई मानहरू 0 र 1 (झूटो, सत्य)। उनको विधि WaitOne() यदि मान ० थियो भने कलिङ थ्रेडलाई रोक्छ, र यदि १, यसलाई ० मा घटाउँछ र यसलाई छोड्छ। एक विधि Set() 1 मा बढ्छ र एक वेटर मार्फत जान दिन्छ, जसले फेरि 0 मा घटाउँछ। सबवे टर्नस्टाइल जस्तै कार्य गर्दछ।

समाधानलाई जटिल बनाऔं र प्रत्येक दार्शनिकको लागि लक प्रयोग गरौं, र सबैको लागि एकै पटक होइन। ती। अब एकै पटक धेरै दार्शनिक हुन सक्छन्, एकै होइन। तर हामी फेरि तालिकामा पहुँचलाई सही रूपमा अवरुद्ध गर्छौं, दौडहरू (दौड अवस्थाहरू) बेवास्ता गर्दै, पक्का बेट्स लिनुहोस्।

// Для блокирования отдельного философа.
// Инициализируется: new AutoResetEvent(true) для каждого.
private AutoResetEvent[] philosopherEvents;

// Для доступа к вилкам / доступ к столу.
private AutoResetEvent tableEvent = new AutoResetEvent(true);

// Рождение философа.
public void Run(int i, CancellationToken token)
{
    while (true)
    {
        TakeForks(i); // Ждет вилки.
        // Обед. Может быть и дольше.
        eatenFood[i] = (eatenFood[i] + 1) % (int.MaxValue - 1);
        PutForks(i); // Отдать вилки и разблокировать соседей.
        Think(i);
        if (token.IsCancellationRequested) break;
    }
}

// Ожидать вилки в блокировке.
void TakeForks(int i)
{
    bool hasForks = false;
    while (!hasForks) // Попробовать еще раз (блокировка не здесь).
    {
        // Исключающий доступ к столу, без гонок за вилками.
        tableEvent.WaitOne();
        if (forks[Left(i)] == 0 && forks[Right(i)] == 0)
            forks[Left(i)] = forks[Right(i)] = i + 1;
        hasForks = forks[Left(i)] == i + 1 && forks[Right(i)] == i + 1;
        if (hasForks)
            // Теперь философ поест, выйдет из цикла. Если Set 
            // вызван дважды, то значение true.
            philosopherEvents[i].Set();
        // Разблокировать одного ожидающего. После него значение tableEvent в false.
        tableEvent.Set(); 
        // Если имеет true, не блокируется, а если false, то будет ждать Set от соседа.
        philosopherEvents[i].WaitOne();
    }
}

// Отдать вилки и разблокировать соседей.
void PutForks(int i)
{
    tableEvent.WaitOne(); // Без гонок за вилками.
    forks[Left(i)] = 0;
    // Пробудить левого, а потом и правого соседа, либо AutoResetEvent в true.
    philosopherEvents[LeftPhilosopher(i)].Set();
    forks[Right(i)] = 0;
    philosopherEvents[RightPhilosopher(i)].Set();
    tableEvent.Set();
}

यहाँ के भइरहेको छ भनेर बुझ्नको लागि, दार्शनिकले काँटा लिन असफल भएको अवस्थामा विचार गर्नुहोस्, त्यसपछि उनको कार्यहरू निम्नानुसार हुनेछ। ऊ टेबुलमा पहुँचको लागि पर्खिरहेको छ। यो प्राप्त गरेपछि, उसले काँटा लिन कोसिस गर्छ। काम लागेन । यसले तालिकामा पहुँच दिन्छ (आपसी बहिष्कार)। र आफ्नो "टर्नस्टाइल" पार गर्दछ (AutoResetEvent) (तिनीहरू सुरुमा खुला छन्)। यो फेरि चक्रमा जान्छ, किनभने ऊसँग काँटा छैन। उसले तिनीहरूलाई लिन खोज्छ र आफ्नो "टर्नस्टाइल" मा रोक्छ। दायाँ वा बाँयामा केही भाग्यशाली छिमेकी, खाना सकिएपछि, हाम्रो दार्शनिकलाई "उनको टर्नस्टाइल खोल्दै।" हाम्रो दार्शनिकले यसलाई दोस्रो पटक पास गर्छ (र यो यसको पछाडि बन्द हुन्छ)। उसले तेस्रो पटक काँटा लिन कोसिस गर्छ। भाग्यले साथ दिओस्। र उसले खाना खानको लागि आफ्नो टर्नस्टाइल पार गर्दछ।

जब त्यस्ता कोडमा अनियमित त्रुटिहरू हुन्छन् (तिनीहरू सधैं अवस्थित हुन्छन्), उदाहरणका लागि, छिमेकीलाई गलत रूपमा निर्दिष्ट गरिएको छ वा उही वस्तु सिर्जना गरिएको छ। AutoResetEvent सबैको लागि (Enumerable.Repeat), तब दार्शनिकहरू विकासकर्ताहरूको लागि पर्खिरहेका हुनेछन्, किनभने यस्तो कोडमा त्रुटिहरू खोज्नु एकदम गाह्रो काम हो। यस समाधानको साथ अर्को समस्या यो हो कि यसले कुनै दार्शनिक भोकै मर्ने छैन भन्ने ग्यारेन्टी गर्दैन।

हाइब्रिड समाधान

हामीले समयको लागि दुई दृष्टिकोणहरू हेरेका छौं, जब हामी प्रयोगकर्ता मोड र लूपमा रहन्छौं, र जब हामी कर्नेल मार्फत थ्रेड ब्लक गर्छौं। पहिलो विधि छोटो तालाहरूको लागि राम्रो छ, दोस्रो लामोको लागि। लूपमा परिवर्तन हुनको लागि पहिले संक्षिप्त रूपमा पर्खनु पर्ने हुन्छ, र पर्खाइ लामो हुँदा थ्रेडलाई रोक्नुहोस्। यो दृष्टिकोण तथाकथित मा लागू गरिएको छ। हाइब्रिड संरचनाहरू। यहाँ कर्नेल मोडको लागि समान निर्माणहरू छन्, तर अब प्रयोगकर्ता मोड लुपको साथ: SemaphorSlim, ManualResetEventSlim आदि यहाँ सबैभन्दा लोकप्रिय डिजाइन हो Monitor, किनभने C# मा एक प्रसिद्ध छ lock वाक्य रचना। Monitor यो 1 (mutex) को अधिकतम मान भएको समान सेमाफोर हो, तर लूप, पुनरावृत्ति, कन्डिशन भेरिएबल ढाँचा (तलको बारेमा थप), आदिमा पर्खन समर्थन सहित। यसको समाधान हेरौं।

// Спрячем объект для Монитора от всех, чтобы без дедлоков.
private readonly object _lock = new object();
// Время ожидания потока.
private DateTime?[] _waitTimes = new DateTime?[philosophersAmount];

public void Run(int i, CancellationToken token)
{
    while (true)
    {
        TakeForks(i);
        eatenFood[i] = (eatenFood[i] + 1) % (int.MaxValue - 1);
        PutForks(i);
        Think(i);
        if (token.IsCancellationRequested) break;
    }
}

// Наше сложное условие для Condition Variable паттерна.
bool CanIEat(int i)
{
    // Если есть вилки:
    if (forks[Left(i)] != 0 && forks[Right(i)] != 0)
        return false;
    var now = DateTime.Now;
    // Может, если соседи не более голодные, чем текущий.
    foreach(var p in new int[] {LeftPhilosopher(i), RightPhilosopher(i)})
        if (_waitTimes[p] != null && now - _waitTimes[p] > now - _waitTimes[i])
            return false;
    return true;
}

void TakeForks(int i)
{
    // Зайти в Монитор. То же самое: lock(_lock) {..}.
    // Вызываем вне try, чтобы возможное исключение выбрасывалось выше.
    bool lockTaken = false;
    Monitor.Enter(_lock, ref lockTaken);
    try
    {
        _waitTimes[i] = DateTime.Now;
        // Condition Variable паттерн. Освобождаем лок, если не выполненно 
        // сложное условие. И ждем пока кто-нибудь сделает Pulse / PulseAll.
        while (!CanIEat(i))
            Monitor.Wait(_lock); 
        forks[Left(i)] = i + 1;
        forks[Right(i)] = i + 1;
        _waitTimes[i] = null;
    }
    finally
    {
        if (lockTaken) Monitor.Exit(_lock);
    }
}

void PutForks(int i)
{
    // То же самое: lock (_lock) {..}.
    bool lockTaken = false;
    Monitor.Enter(_lock, ref lockTaken);
    try
    {
        forks[Left(i)] = 0;
        forks[Right(i)] = 0;
        // Освободить все потоки в очереди ПОСЛЕ вызова Monitor.Exit.
        Monitor.PulseAll(_lock); 
    }
    finally
    {
        if (lockTaken) Monitor.Exit(_lock);
    }
}

यहाँ हामी फेरि फोर्कहरूमा पहुँचको लागि सम्पूर्ण तालिकालाई अवरुद्ध गर्दैछौं, तर अब हामी सबै थ्रेडहरू एकैचोटि अनब्लक गर्दैछौं, र कसैले खाना खाएपछि छिमेकीहरूलाई होइन। ती। पहिले, कसैले खान्छ र छिमेकीहरूलाई रोक्छ, र जब यो समाप्त हुन्छ, तर तुरुन्तै फेरि खान चाहन्छ, ऊ अवरोधमा जान्छ र छिमेकीहरूलाई जगाउँछ, किनभने। यसको प्रतीक्षा समय कम छ।

यसरी हामी गतिरोध र केही दार्शनिकको भोकबाट बच्न सक्छौं। हामी छोटो पर्खाइको लागि लूप प्रयोग गर्छौं र लामो समयको लागि थ्रेडलाई रोक्छौं। सबैलाई एकैचोटि अनब्लक गर्नु ढिलो हुन्छ यदि छिमेकीलाई मात्र अनब्लक गरिएको थियो, जस्तै समाधानमा AutoResetEvent, तर भिन्नता ठूलो हुनु हुँदैन, किनभने थ्रेडहरू पहिले प्रयोगकर्ता मोडमा रहनुपर्छ।

У lock सिन्ट्याक्समा नराम्रो आश्चर्य छ। प्रयोग गर्न सिफारिस गर्नुहोस् Monitor प्रत्यक्ष [रिक्टर] [एरिक लिप्पर्ट]। ती मध्ये एक हो lock सधैं बाहिर Monitor, त्यहाँ अपवाद भए पनि, जसमा अर्को थ्रेडले साझा मेमोरी अवस्था परिवर्तन गर्न सक्छ। यस्तो अवस्थामा, यो प्रायः डेडलकमा जानु वा कुनै पनि तरिकाले कार्यक्रमलाई सुरक्षित रूपमा समाप्त गर्नु राम्रो हुन्छ। अर्को आश्चर्य यो हो कि मनिटरले सिंक्रोनाइजेसन ब्लकहरू प्रयोग गर्दछ (SyncBlock), जुन सबै वस्तुहरूमा अवस्थित हुन्छ। त्यसकारण, यदि अनुपयुक्त वस्तु चयन गरिएको छ भने, तपाइँ सजिलैसँग डेडलक प्राप्त गर्न सक्नुहुन्छ (उदाहरणका लागि, यदि तपाइँ इन्टरन्ड स्ट्रिङमा लक गर्नुहुन्छ)। हामी यसको लागि सधैं लुकेको वस्तु प्रयोग गर्छौं।

सर्त चर ढाँचाले तपाईंलाई केही जटिल अवस्थाको अपेक्षालाई थप संक्षिप्त रूपमा कार्यान्वयन गर्न अनुमति दिन्छ। .NET मा, यो अपूर्ण छ, मेरो विचारमा, किनभने सिद्धान्तमा, त्यहाँ धेरै चरहरूमा धेरै लामहरू हुनुपर्छ (जस्तै पोसिक्स थ्रेडहरूमा), र एउटै लोकमा होइन। त्यसोभए कसैले तिनीहरूलाई सबै दार्शनिकहरूको लागि बनाउन सक्छ। तर यस फारममा पनि, यसले तपाईंलाई कोड कम गर्न अनुमति दिन्छ।

धेरै दार्शनिक वा async / await

ठीक छ, अब हामी प्रभावकारी रूपमा थ्रेडहरू ब्लक गर्न सक्छौं। तर के हुन्छ यदि हामीसँग धेरै दार्शनिकहरू छन्? १००? 100? उदाहरणका लागि, हामीले वेब सर्भरमा 10000 अनुरोधहरू प्राप्त गरेका छौं। प्रत्येक अनुरोधको लागि थ्रेड सिर्जना गर्न यो ओभरहेड हुनेछ, किनभने धेरै थ्रेडहरू समानान्तरमा चल्ने छैनन्। त्यहाँ धेरै तार्किक कोरहरू मात्र चल्नेछ (मसँग 100000 छ)। र अरू सबैले मात्र स्रोतहरू लिनेछन्। यस समस्याको एक समाधान async / प्रतीक्षा ढाँचा हो। यसको विचार यो हो कि प्रकार्यले थ्रेड समात्दैन यदि यसलाई जारी राख्नको लागि केहि पर्खनु पर्छ। र जब यसले केहि गर्छ, यसले यसको कार्यान्वयन पुन: सुरु गर्छ (तर एउटै थ्रेडमा आवश्यक छैन!)। हाम्रो अवस्थामा, हामी फोर्कको लागि पर्खनेछौं।

SemaphoreSlim यसका लागि छ WaitAsync() विधि। यहाँ यो ढाँचा प्रयोग गरी कार्यान्वयन गरिएको छ।

// Запуск такой же, как раньше. Где-нибудь в программе:
Task.Run(() => Run(i, cancelTokenSource.Token));

// Запуск философа.
// Ключевое слово async -- компилятор транслирует этот метот в асинхронный.
public async Task Run(int i, CancellationToken token)
{
    while (true)
    {
        // await -- будем ожидать какого-то события.
        await TakeForks(i);
        // После await, продолжение возможно в другом потоке.
        eatenFood[i] = (eatenFood[i] + 1) % (int.MaxValue - 1);
        // Может быть несколько событий для ожидания.
        await PutForks(i);

        Think(i);

        if (token.IsCancellationRequested) break;
    }
}

async Task TakeForks(int i)
{
    bool hasForks = false;
    while (!hasForks)
    {
        // Взаимоисключающий доступ к столу:
        await _tableSemaphore.WaitAsync();
        if (forks[Left(i)] == 0 && forks[Right(i)] == 0)
        {
            forks[Left(i)] = i+1;
            forks[Right(i)] = i+1;
            hasForks = true;
        }
        _tableSemaphore.Release();
        // Будем ожидать, чтобы сосед положил вилки:
        if (!hasForks)
            await _philosopherSemaphores[i].WaitAsync();
    }
}

// Ждем доступа к столу и кладем вилки.
async Task PutForks(int i)
{
    await _tableSemaphore.WaitAsync();
    forks[Left(i)] = 0;
    // "Пробудить" соседей, если они "спали".
    _philosopherSemaphores[LeftPhilosopher(i)].Release();
    forks[Right(i)] = 0;
    _philosopherSemaphores[RightPhilosopher(i)].Release();
    _tableSemaphore.Release();
}

संग विधि async / await एक कठिन राज्य मेसिनमा अनुवाद गरिएको छ जसले तुरुन्तै यसको आन्तरिक फर्काउँछ Task। यसको माध्यमबाट, तपाइँ विधिको समाप्तिको लागि पर्खन सक्नुहुन्छ, यसलाई रद्द गर्न सक्नुहुन्छ, र तपाइँ कार्यसँग गर्न सक्ने सबै कुराहरू। विधि भित्र, राज्य मेसिनले कार्यान्वयन नियन्त्रण गर्दछ। तल्लो रेखा यो हो कि यदि त्यहाँ कुनै ढिलाइ छैन भने, कार्यान्वयन सिंक्रोनस हुन्छ, र यदि त्यहाँ छ भने, थ्रेड जारी हुन्छ। यो राम्रोसँग बुझ्नको लागि, यो राज्य मेसिन हेर्न राम्रो छ। तपाईं यी बाट चेन बनाउन सक्नुहुन्छ async / await विधिहरू।

परीक्षण गरौं। 100 तार्किक कोर, 4 सेकेन्ड भएको मेसिनमा 8 दार्शनिकहरूको काम। मनिटरको साथ अघिल्लो समाधानले पहिलो 4 थ्रेडहरू मात्र चलाएको थियो र बाँकी सबै चलेको थिएन। यी 4 थ्रेडहरू मध्ये प्रत्येक लगभग 2ms को लागि निष्क्रिय थियो। र async/await solution सबै 100 दौडियो, प्रत्येक 6.8 सेकेन्डको औसत पर्खाइको साथ। निस्सन्देह, वास्तविक प्रणालीहरूमा, 6 सेकेन्डको लागि निष्क्रिय अस्वीकार्य छ र यो जस्तै धेरै अनुरोधहरू प्रशोधन नगर्नु राम्रो छ। मोनिटरको साथ समाधान सबै स्केलेबल हुन सकेन।

निष्कर्षमा

तपाईंले यी साना उदाहरणहरूबाट देख्न सक्नुहुन्छ, .NET ले धेरै सिङ्क्रोनाइजेसन निर्माणहरूलाई समर्थन गर्दछ। यद्यपि, यो सधैं तिनीहरूलाई कसरी प्रयोग गर्ने स्पष्ट छैन। मलाई आशा छ कि यो लेख उपयोगी थियो। अहिलेको लागि, यो अन्त्य हो, तर त्यहाँ अझै धेरै रोचक चीजहरू बाँकी छन्, उदाहरणका लागि, थ्रेड-सेफ संग्रहहरू, TPL डाटाफ्लो, प्रतिक्रियाशील प्रोग्रामिङ, सफ्टवेयर लेनदेन मोडेल, आदि।

स्रोतहरू

• प्रवाह दृश्य: Concurrency Visualizer
• MSDN: थ्रेडि।, एसिन्क्रोनस प्रोग्रामिङ पैटर्न र अरू धेरै अन्य
• [रिक्टर] - CLR मार्फत C#, जेफ्री रिक्टर
• [एरिक लिप्पर्ट] - ताला बारे
• स्रोत कोड
• तस्विर - "तरवारहरू बीच नृत्य", G. Semiradsky

स्रोत: www.habr.com