वेल-फेड फिलॉसॉफर किंवा स्पर्धात्मक .NET प्रोग्रामिंग

उदाहरण म्हणून फिलॉसॉफर्स डायनिंग प्रॉब्लेम वापरून .Net मध्ये समवर्ती आणि समांतर प्रोग्रामिंग कसे कार्य करते ते पाहू. योजना अशी आहे, थ्रेड्स/प्रोसेसच्या सिंक्रोनाइझेशनपासून ते अभिनेता मॉडेलपर्यंत (पुढील भागांमध्ये). लेख पहिल्या ओळखीसाठी किंवा आपले ज्ञान ताजेतवाने करण्यासाठी उपयुक्त असू शकतो.

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

उद्दिष्ट

एड्सगर डिजक्स्ट्राने ही समस्या 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), जे अणू अनुक्रमिक वाचन आणि लेखनासाठी मेमरीचा तुकडा लॉक करते. आणि SpinWait रचना समतुल्य आहे 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)
    );
}

या संहितेतील महत्त्वाची गोष्ट म्हणजे चारपैकी दोन तत्त्वज्ञ त्यांचा डावा काटा खाली ठेवायला विसरतात. आणि असे दिसून आले की ते अधिक अन्न खातात, तर इतरांना उपाशी राहण्यास सुरुवात होते, जरी थ्रेड्सना समान प्राधान्य असते. येथे ते पूर्णपणे उपाशी नाहीत, कारण. वाईट तत्वज्ञानी कधी कधी त्यांचे काटे मागे ठेवतात. असे दिसून आले की चांगले लोक वाईट लोकांपेक्षा 5 पट कमी खातात. त्यामुळे कोडमधील लहान त्रुटीमुळे कार्यप्रदर्शनात घट होते. येथे हे देखील लक्षात घेण्यासारखे आहे की एक दुर्मिळ परिस्थिती शक्य आहे जेव्हा सर्व तत्त्वज्ञ डावा काटा घेतात, तेथे कोणीही उजवा नसतो, त्यांनी डावीकडे ठेवले, थांबा, पुन्हा डावीकडे घ्या, इ. ही परिस्थिती देखील उपासमारीची आहे, अधिकाधिक गतिरोधक आहे. मी त्याची पुनरावृत्ती करण्यात अयशस्वी झालो. खाली अशा परिस्थितीचे चित्र आहे जिथे दोन वाईट तत्वज्ञांनी दोन्ही काटे घेतले आहेत आणि दोन चांगले भुकेले आहेत.

येथे आपण पाहू शकता की धागे कधीकधी जागे होतात आणि संसाधन मिळविण्याचा प्रयत्न करतात. चारपैकी दोन कोर काहीही करत नाहीत (वरील हिरवा आलेख).

एका तत्ववेत्त्याचा मृत्यू

बरं, तत्त्वज्ञांच्या वैभवशाली रात्रीच्या जेवणात व्यत्यय आणणारी आणखी एक समस्या म्हणजे त्यांच्यापैकी एखादा अचानक हातात काटे घेऊन मरण पावला (आणि ते त्याला असेच दफन करतील). मग शेजारी जेवणाशिवाय सोडले जातील. आपण स्वत: या केससाठी एक उदाहरण कोड घेऊन येऊ शकता, उदाहरणार्थ, ते बाहेर फेकले आहे 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 कदाचित 53 पट हळू SpinLock [रिश्टर]. परंतु त्यांच्या मदतीने, आपण संपूर्ण सिस्टममध्ये प्रक्रिया समक्रमित करू शकता, व्यवस्थापित किंवा नाही.

अर्धशतकापूर्वी डिजक्स्ट्राने प्रस्तावित केलेला सेमाफोर येथे मूळ रचना आहे. सेमाफोर म्हणजे, सोप्या भाषेत, सिस्टमद्वारे व्यवस्थापित केलेला एक सकारात्मक पूर्णांक आणि त्यावर दोन ऑपरेशन्स, वाढ आणि घट. जर ते कमी होण्यास अयशस्वी झाले, शून्य, तर कॉलिंग थ्रेड अवरोधित केला जाईल. जेव्हा संख्या इतर काही सक्रिय थ्रेड/प्रक्रियेद्वारे वाढविली जाते, तेव्हा थ्रेड वगळले जातात आणि पास केलेल्या संख्येने सेमाफोर पुन्हा कमी केला जातो. सेमाफोर असलेल्या ट्रेन्सची कल्पना करता येते. .NET समान कार्यक्षमतेसह अनेक रचना ऑफर करते: AutoResetEvent, ManualResetEvent, Mutex आणि मी Semaphore. आम्ही वापरू AutoResetEvent, या बांधकामांपैकी ही सर्वात सोपी आहे: फक्त दोन मूल्ये 0 आणि 1 (खोटे, खरे). तिची पद्धत WaitOne() जर मूल्य 0 असेल तर कॉलिंग थ्रेड ब्लॉक करते आणि जर 1 असेल तर ते 0 वर कमी करते आणि ते वगळते. एक पद्धत 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 (म्युटेक्स) चे कमाल मूल्य असलेले हे समान सेमाफोर आहे, परंतु लूपमध्ये प्रतीक्षा करण्यासाठी समर्थनासह, पुनरावृत्ती, कंडिशन व्हेरिएबल पॅटर्न (खाली त्याबद्दल अधिक), इ. यासह एक उपाय पाहू या.

// Спрячем объект для Монитора от всех, чтобы без дедлоков.
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 विनंत्या मिळाल्या. प्रत्येक विनंतीसाठी थ्रेड तयार करणे ओव्हरहेड असेल, कारण इतके धागे समांतर चालणार नाहीत. लॉजिकल कोर आहेत तितकेच चालतील (माझ्याकडे 4 आहेत). आणि बाकीचे सगळे फक्त संसाधने काढून घेतील. या समस्येचा एक उपाय म्हणजे async/await pattern. त्याची कल्पना अशी आहे की फंक्शन थ्रेड धरून ठेवत नाही जर त्याला काहीतरी सुरू ठेवण्यासाठी प्रतीक्षा करावी लागेल. आणि जेव्हा ते काही करते, तेव्हा ते त्याची अंमलबजावणी पुन्हा सुरू करते (परंतु त्याच धाग्यावर आवश्यक नाही!). आमच्या बाबतीत, आम्ही काट्याची प्रतीक्षा करू.

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 सोल्यूशन प्रत्येकी 100 सेकंदांच्या सरासरी प्रतीक्षासह सर्व 6.8 धावले. अर्थात, रिअल सिस्टीममध्ये, 6 सेकंदांसाठी निष्क्रियता अस्वीकार्य आहे आणि अशा अनेक विनंत्यांवर प्रक्रिया न करणे चांगले आहे. मॉनिटरसह सोल्यूशन अजिबात स्केलेबल नाही.

निष्कर्ष

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

स्त्रोत

• प्रवाह व्हिज्युअलायझेशन: कॉन्करन्सी व्हिज्युअलायझर
• MSDN: थ्रेडिंग, असिंक्रोनस प्रोग्रामिंग नमुने आणि इतर अनेक डॉ.
• [रिश्टर] - C#, जेफ्री रिक्टर मार्गे CLR
• [एरिक लिप्पर्ट] - लॉक बद्दल
• स्त्रोत कोड
• चित्र - "तलवारींमध्ये नृत्य", जी. सेमिराडस्की

स्त्रोत: www.habr.com