👲 ✋🏾 🤶🏽 सी # में एसिंक्रोनस और सिंक्रोनाइज़ेशनकोटेक्स्ट 👨🏽‍🎓 ↕️ ♨️

निरंतरता: भाग III ।

Async ( भाग I ) के बारे में पिछला पोस्ट एक परिचय था। इसमें, मैंने जो विषय शुरू किया है, उसे जारी रखूंगा: मैं इस बारे में बात करूंगा कि एसिंक्रोनस सिंक्रोनाइज़ेशन कॉन्टेक्स्ट के साथ कैसे इंटरैक्ट करता है, और यह एसिंक्रोनस ग्राफिक्स अनुप्रयोगों के विकास को कैसे प्रभावित करता है।

परीक्षण स्थल भोजनप्रदर्शनी उदाहरण है, जो अतुल्यकालिक प्रोग्रामिंग के लिए एक विस्तार के साथ आता है। यह कार्यक्रम डायजस्ट्रा के भोजन दार्शनिकों के प्रसिद्ध कार्य ( लिंक ) का एक दृश्य है। आगे पढ़ने से पहले, समस्या की स्थितियों से खुद को परिचित करना बेहतर है।

कार्यक्रम छोटा है, इसलिए इसकी समीक्षा करते हैं। बहुत शुरुआत में, कक्षाएं परिभाषित की जाती हैं जो समस्या के मुख्य सार का प्रतिनिधित्व करती हैं: दार्शनिक, दार्शनिक और कांटा की स्थिति।

बफ़रब्लॉक क्लास को एक कांटे के रूप में प्रयोग किया जाता है, जो System.Threading.Tasks.Dataflow नाम स्थान पर स्थित है। यह स्थान आपको डेटा प्रवाह के आधार पर बहु-थ्रेडेड एप्लिकेशन लिखने की अनुमति देता है। इस दृष्टिकोण का सबसे सरल उदाहरण वे चैनल हैं जो लिम्बो, गो, एक्सम में उपयोग किए जाते हैं; उनका सार यह है कि दो स्ट्रीम चैनल (कतार का एक एनालॉग) के माध्यम से बातचीत करते हैं, जिसमें आप लिख सकते हैं और पढ़ सकते हैं, यदि धारा चैनल से पढ़ने की कोशिश करती है और चैनल खाली है, तो चैनल में डेटा दिखाई देने तक स्ट्रीम अवरुद्ध हो जाती है। आम वस्तुओं की अस्वीकृति और डेटा एक्सचेंज और सिंक्रोनाइज़ेशन टूल के लिए चैनलों का उपयोग आपको अधिक समझने योग्य और सुरक्षित कोड लिखने की अनुमति देता है। बफ़रब्लॉक एक ऐसा चैनल है, पोस्ट मेथड डेटा जोड़ता है, रिसीव करता है, और रिसीवेसिंक एक एक्सटेंशन तरीका है, जो एसिंक्रोनस रूप से डेटा प्राप्त करता है। समस्या का सार पूरी तरह से इस वर्ग में निहित है: एक सुलभ प्लग का वर्णन एक चैनल द्वारा किया जाता है जिसमें कुछ होता है, एक व्यस्त प्लग को एक खाली चैनल द्वारा वर्णित किया जाता है, यदि एक दार्शनिक निष्पादन का प्रवाह है, तो एक मुफ्त प्लग (चैनल) का उपयोग करते समय, यह निष्पादित करना जारी रखेगा, और एक व्यस्त द्वारा, यह होगा। इंतजार करना।

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

जैसा कि मैंने पहले ही लिखा है, दार्शनिक स्वयं को निष्पादन के धागे (RunPhilosopherAsync विधि) द्वारा दर्शाया जाएगा।

using Philosopher = Ellipse; using Fork = BufferBlock<bool>;

MainWindow विधि व्यावहारिक रूप से दिलचस्प नहीं है, इसमें वर्ग संरचनाएं आरंभीकृत हैं। केवल एक चीज जो उसके बारे में देखी जा सकती है वह यह है कि वह एक ऐसी विधि को कहता है जिसके हस्ताक्षर में async शून्य है, ऐसे तरीकों को कॉल करके हम एक अतुल्यकालिक ऑपरेशन लॉन्च करते हैं और इस पर नियंत्रण खो देते हैं, उदाहरण के लिए, हम इसे पूरा होने का इंतजार नहीं कर सकते।

 public MainWindow() { for (int i = 0; i < philosophers.Length; i++) { diningTable.Children.Add(philosophers[i] = CreatePhilosopher()); forks[i] = new Fork(); forks[i].Post(true); } //      for (int i = 0; i < philosophers.Length; i++) { RunPhilosopherAsync( philosophers[i], i < philosophers.Length - 1 ? forks[i] : forks[1], i < philosophers.Length - 1 ? forks[i + 1] : forks[i] ); } }

RunPhilosopherAsync कोड दार्शनिक के कार्यों का वर्णन करता है, यह विशेष रूप से अतुल्यकालिक के लिए बहुत सीधा है: सोचें, कांटे की प्रतीक्षा करें, खाएं, कांटा वापस डालें और फिर से सोचें। ठहराव (टास्कएक्स। डेल) की व्यवस्था की जाती है ताकि आप विभिन्न चरणों का पालन कर सकें।

 private async void RunPhilosopherAsync(Philosopher philosopher, Fork fork1, Fork fork2) { // ,  , ,     while (true) { //  () philosopher.Fill = Brushes.Yellow; await TaskEx.Delay(_rand.Next(10) * TIMESCALE); //   () philosopher.Fill = Brushes.Red; await fork1.ReceiveAsync(); await fork2.ReceiveAsync(); //  () philosopher.Fill = Brushes.Green; await TaskEx.Delay(_rand.Next(10) * TIMESCALE); //       fork1.Post(true); fork2.Post(true); } }

इस कोड के बारे में क्या?

सबसे पहले, यह मामले में काम नहीं करता है (गतिरोध) जब रेखा के कारण दार्शनिकों की संख्या दो होती है:

 i < philosophers.Length - 1 ? forks[i] : forks[1]

कांटे [1] को कांटे [0] से बदलना आवश्यक है। लेकिन यह नाइट-पिकिंग है, दार्शनिकों की संख्या पांच होने दें।

दूसरे, कोड को काम नहीं करना चाहिए, क्योंकि हम दूसरे तत्व से गुई तत्व तक पहुंच रहे हैं, लेकिन सबसे अजीब बात यह है कि यह काम करता है। यदि आपको कोड में async / प्रतीक्षा से छुटकारा मिलता है, तो "x.Wait ()", और "RunPhilosopherAsync (...)" के साथ "नई टास्क () =>> RunPhilosopherAsync (...)" के साथ हर जगह "प्रतीक्षा x" की जगह ले लें। प्रारंभ करें () "और async टोकन को हटाकर, हमें अपेक्षित InvalidOperationException मिलता है।

अब यह स्पष्ट है कि सभी जादू का इंतजार है।

.नेट फ्रेमवर्क में गुइ-धाराओं के साथ सहभागिता

याद रखें कि कैसे यह .Net फ्रेमवर्क में गुई थ्रेड्स के साथ बातचीत करने के लिए प्रथागत है।

WinForms के मामले में, किसी भी नियंत्रण के लिए यह पर्याप्त है कि आह्वान विधि को कॉल करें और इसे कोड के साथ एक प्रतिनिधि को पास करें जिसे gui थ्रेड में निष्पादित किया जाना चाहिए। WPF के मामले में, आपको किसी भी नियंत्रण की डिस्पैचर संपत्ति तक पहुंचने और इनवोक विधि को कॉल करने की आवश्यकता है, फिर से इसे एक प्रतिनिधि को पास करना।

यह क्रिस्टोफर के पैटर्न की क्लासिक परिभाषा की शुरुआत की याद दिलाता है: एक समस्या जो खुद को बार-बार दोहरा रही है। समस्या को एक विशिष्ट थ्रेड में कोड निष्पादित करने की आवश्यकता के रूप में वर्णित किया जा सकता है, जब इनिशलाइज़र दूसरे थ्रेड से कोड होता है। वास्तव में, यह समस्या gui के लिए विशिष्ट नहीं है, यह COM और WCF में भी पॉप अप करता है ... यह तर्कसंगत है कि इसका एक समाधान होना चाहिए, थ्रेड इसमें WinForms और WPF नियंत्रणों के समान कोड चलाने के लिए एक साधन प्रदान करना चाहिए । इस तरह का एक समाधान है, एक प्रकार का ऑब्जेक्ट SynchronizationContext दूसरे धागे पर कोड निष्पादित करने के लिए Send और Post (अतुल्यकालिक) तरीके प्रदान करता है। किसी भी थ्रेड के SynchronizationContext के प्रकार के ऑब्जेक्ट तक पहुंचने के लिए, आपको इस थ्रेड में SynchronizationContext.Current (प्रति थ्रेड सिंगलटन) तक पहुंचने की आवश्यकता है।

यह महत्वपूर्ण है कि सिंक्रोनाइज़ेशन कॉनटेक्स्ट और स्ट्रीम संगत हैं, उदाहरण के लिए, यदि स्ट्रीम ईवेंट लूप पर आधारित है, तो सिंक्रोनाइज़ेशन कॉन्टेक्स्ट की इवेंट क्यू तक पहुँच होनी चाहिए। यही है, प्रत्येक ईवेंट लूप कार्यान्वयन को सिंक्रोनाइज़ेशन कॉन्टेक्स्ट विधियों को इनहेरिट और ओवरराइड करने की आवश्यकता है। यदि आप एक SynchronizationContext ऑब्जेक्ट बनाते हैं, तो Send और Post को कॉल करते समय, यह थ्रेडपूल से थ्रेड का उपयोग करेगा।

अब हम मान सकते हैं कि एसिंक्रोनस ऑपरेशन के परिणाम में सिंक्रोनाइज़ेशन कॉन्टेक्स्ट ऑब्जेक्ट का उपयोग करके प्रदर्शन होता है, जो इसे पहली कॉल पर प्राप्त होता है। इस परिकल्पना को सत्यापित करना आसान है: अपना सिंक्रोनाइज़ेशन निर्धारित करें:

 class MyContext : SynchronizationContext { public override void Post(SendOrPostCallback d, object state) { Console.WriteLine("MyContext.Post"); base.Post(d, state); } public override void Send(SendOrPostCallback d, object state) { Console.WriteLine("MyContext.Send"); base.Send(d, state); } } class Program { static async Task SavePage(string file, string a) { using (var stream = File.AppendText(file)) { var html = await new WebClient().DownloadStringTaskAsync(a); await stream.WriteAsync(html); } } static void Main(string[] args) { SynchronizationContext.SetSynchronizationContext(new MyContext()); var task = SavePage("habrahabr", "http://habrahabr.ru"); task.Wait(); } }

स्टार्टअप पर, "MyContext.Post" को कई बार प्रदर्शित किया जाएगा, इसलिए प्रतीक्षारत वास्तव में SynchronizationContext का उपयोग किया जाता है।

निष्कर्ष

तथ्य यह है कि काम पर SynchronizationContext का उपयोग करने वाला तथ्य अतुल्यकालिक ग्राफिक्स अनुप्रयोगों को लिखना और भी आसान बना देता है, क्योंकि हमें इस बात की चिंता नहीं है कि हम किस तत्व में ग्राफिक तत्वों को एक्सेस कर रहे हैं।

वैसे, SynchronizationContext एक अच्छा उदाहरण है जब सिंगलटन एक पूर्ण बुराई नहीं है।

मुझे यह नोट 1 नवंबर के ikvm.net ब्लॉग पोस्ट द्वारा लिखने के लिए कहा गया था। और लेख "अंडरस्टैंडिंग सिंक्रोनाइज़ेशन कॉन्टेक्स्ट" ( भाग I , भाग II और भाग III ) ने मुझे विषय को समझने में मदद की।

सी # में एसिंक्रोनस और सिंक्रोनाइज़ेशनकोटेक्स्ट

इस कोड के बारे में क्या?

.नेट फ्रेमवर्क में गुइ-धाराओं के साथ सहभागिता

निष्कर्ष

More articles: