🕗 😋 👨‍👨‍👧 अच्छी तरह से खिलाया दार्शनिक या प्रतिस्पर्धी .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); }

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

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

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।

Livelock

चित्रा में, थ्रेड्स को अवरुद्ध करना (गतिरोध)। ग्रीन निष्पादन को इंगित करता है, लाल सिंक्रनाइज़ेशन को इंगित करता है, और ग्रे नींद को इंगित करता है। हीरे कार्य के प्रारंभ समय का संकेत देते हैं।

द हंगर ऑफ़ फिलॉसफ़र्स

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

 //      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 नमूना कोड NullReferenceException सकते NullReferenceException , उदाहरण के लिए, दार्शनिक के कांटे लेने के बाद 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; } while(true) { if (!lock) break; } , लेकिन SpinWait (जो वहां उपयोग किया जाता है) की तुलना में और भी अधिक "जादू" के साथ। अब वह जानता है कि जो लोग इंतजार कर रहे हैं उन्हें कैसे गिनें, उन्हें थोड़ा और अधिक सोने के लिए डाल दें। आदि सामान्य तौर पर, अनुकूलन करने के लिए हर संभव प्रयास करता है। लेकिन हमें याद रखना चाहिए कि यह अभी भी एक ही सक्रिय चक्र है जो प्रोसेसर संसाधनों को खाता है और एक धागा रखता है जो भुखमरी का कारण बन सकता है अगर दार्शनिकों में से एक दूसरों पर प्राथमिकता बन जाता है, लेकिन एक सुनहरा कांटा (प्राथमिकता उलटा समस्या) नहीं है। इसलिए, हम इसे केवल किसी भी तृतीय-पक्ष कॉल, नेस्टेड ताले, आदि आश्चर्य के बिना साझा की गई स्मृति में बहुत ही कम परिवर्तनों के लिए उपयोग करते हैं।

spinlock

SpinLock लिए चित्रा। गोल्डन फोर्क के लिए धाराएं लगातार "लड़" रही हैं। विफलताएं होती हैं - आंकड़े में, चयनित क्षेत्र। कोर पूरी तरह से उपयोग नहीं किए जाते हैं: केवल इन चार धागों में से लगभग 2/3।

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

CompareExchange बारे में यह कहने योग्य है कि इसमें केवल CompareExchange नहीं हैं, बल्कि परमाणु पढ़ने और लिखने के अन्य तरीके भी हैं। और मामले में परिवर्तनों को दोहराने के माध्यम से एक और धागा अपने परिवर्तन करने के लिए प्रबंधन करता है (1 पढ़ें, 2 पढ़ें, 2 लिखें, 1 लिखें बुरा है), इसका उपयोग एक मूल्य के जटिल परिवर्तनों (इंटरलॉक किए गए कुछ भी पैटर्न) के लिए किया जा सकता है।

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

एक लूप में संसाधनों को खोने से बचने के लिए, आइए देखें कि आप किसी स्ट्रीम को कैसे ब्लॉक कर सकते हैं। दूसरे शब्दों में, अपने उदाहरण को जारी रखते हुए, हम देखेंगे कि कैसे वेटर दार्शनिक को सोने के लिए रखता है और आवश्यक होने पर ही उसे जगाता है। सबसे पहले, आइए देखें कि ऑपरेटिंग सिस्टम के कर्नेल मोड के माध्यम से ऐसा कैसे करें। उपयोगकर्ता के स्थान की तुलना में वहाँ सभी संरचनाएँ प्रायः धीमी होती हैं। कई बार धीमी, उदाहरण के लिए AutoResetEvent SpinLock [रिक्टर] की तुलना में 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 ऑब्जेक्ट AutoResetEvent गया है ( Enumerable.Repeat ), तो दार्शनिक डेवलपर्स के लिए इंतजार करेंगे, क्योंकि इस तरह के कोड में त्रुटियां खोजना एक कठिन काम है। इस समाधान के साथ एक और समस्या यह है कि यह गारंटी नहीं देता है कि कोई भी दार्शनिक भूखा नहीं रहेगा।

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

जब हम उपयोगकर्ता मोड में रहते हैं और लूप में स्पिन करते हैं और जब हम कर्नेल के माध्यम से एक थ्रेड को ब्लॉक करते हैं, तो हमने दो दृष्टिकोणों की जांच की। पहला तरीका छोटे तालों के लिए अच्छा है, दूसरा लंबे तालों के लिए। अक्सर, आपको पहले लूप में परिवर्तन करने के लिए एक चर की संक्षिप्त रूप से अपेक्षा करनी चाहिए, और फिर प्रतीक्षा लंबी होने पर थ्रेड को ब्लॉक करना होगा। यह दृष्टिकोण तथाकथित में लागू किया गया है संकर डिजाइन। वही ManualResetEventSlim हैं जो कर्नेल मोड के लिए थीं, लेकिन अब उपयोगकर्ता मोड में एक लूप के साथ: 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? 10,000? उदाहरण के लिए, हमें एक वेब सर्वर को 100,000 अनुरोध मिले। प्रत्येक अनुरोध के लिए एक स्ट्रीम बनाना ओवरहेड हो जाएगा, क्योंकि इतने सारे धागे समानांतर में निष्पादित नहीं किए जाएंगे। केवल कई तार्किक कोर निष्पादित किए जाएंगे (मेरे पास 4 हैं)। और बाकी सभी लोग केवल संसाधन लेंगे। इस समस्या का एक समाधान 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 . , , Task. , , . , , , , . . async / await .

. 100 4 , 8 . Monitor 4 , . 4 2. async / await 100, 6.8 . , 6 . Monitor .

निष्कर्ष

, .NET . , , , . . , , , TPL Dataflow, Reactive , Software Transaction .

सूत्रों का कहना है

: Concurrency Visualizer
MSDN: Threading , Asynchronous programming patterns . .
[] — CLR via C#, Jeffrey Richter
[ ] — lock
— " ", .

अच्छी तरह से खिलाया दार्शनिक या प्रतिस्पर्धी .NET प्रोग्रामिंग