🥇 ⬅️ 💾 ConfigureAwait, किसे दोष देना है और क्या करना है? 🛰️ 🕙 👨🏿‍🚀

मेरे व्यवहार में, मुझे अक्सर एक अलग वातावरण में, नीचे दिए गए कोड की तरह लगता है:

[1] var x = FooWithResultAsync(/*...*/).Result; // [2] FooAsync(/*...*/).Wait(); // [3] FooAsync(/*...*/).GetAwaiter().GetResult(); // [4] FooAsync(/*...*/) .ConfigureAwait(false) .GetAwaiter() .GetResult(); // [5] await FooAsync(/*...*/).ConfigureAwait(false) //  [6] await FooAsync(/*...*/)

ऐसी पंक्तियों के लेखकों के साथ संचार से, यह स्पष्ट हो गया कि वे सभी तीन समूहों में विभाजित हैं:

पहला समूह वे हैं, जिन्हें Result/Wait/GetResult कॉल करने के साथ संभावित समस्याओं के बारे में कुछ भी नहीं पता है। इस समूह के प्रोग्रामर के लिए उदाहरण (1-3) और कभी-कभी (6) विशिष्ट होते हैं;
दूसरे समूह में प्रोग्रामर शामिल हैं जो संभावित समस्याओं से अवगत हैं, लेकिन वे अपनी घटना के कारणों को नहीं जानते हैं। इस समूह के डेवलपर्स, एक तरफ, (1-3 और 6) जैसी लाइनों से बचने की कोशिश करते हैं, लेकिन, दूसरे पर, दुरुपयोग कोड जैसे (4-5);
तीसरा समूह, मेरे अनुभव में सबसे छोटा, वे प्रोग्रामर हैं जो जानते हैं कि कोड (1-6) कैसे काम करता है, और इसलिए, एक सूचित विकल्प बना सकता है।

क्या जोखिम संभव है, और कोड का उपयोग करते समय यह कितना बड़ा है, जैसा कि ऊपर दिए गए उदाहरणों में है, निर्भर करता है, जैसा कि मैंने पहले पर्यावरण पर उल्लेख किया है ।

जोखिम और उनके कारण

उदाहरण (1-6) दो समूहों में विभाजित हैं। पहला समूह कोड है जो कॉलिंग थ्रेड को ब्लॉक करता है। इस समूह में (1-4) शामिल हैं।
एक धागे को अवरुद्ध करना अक्सर एक बुरा विचार है। क्यों? सादगी के लिए, हम मानते हैं कि सभी धागे किसी न किसी थ्रेड पूल से आवंटित किए जाते हैं। यदि प्रोग्राम में ताला है, तो इससे पूल से सभी थ्रेड्स का चयन हो सकता है। सर्वोत्तम स्थिति में, यह कार्यक्रम को धीमा कर देगा और संसाधनों के अक्षम उपयोग को बढ़ावा देगा। सबसे खराब स्थिति में, यह गतिरोध पैदा कर सकता है, जब किसी कार्य को पूरा करने के लिए अतिरिक्त धागे की आवश्यकता होती है, लेकिन पूल इसे आवंटित नहीं कर सकता है।
इस प्रकार, जब कोई डेवलपर (1-4) कोड लिखता है, तो उसे सोचना चाहिए कि ऊपर वर्णित स्थिति कितनी संभावित है।

लेकिन चीजें बहुत खराब हो जाती हैं जब हम एक ऐसे वातावरण में काम करते हैं जिसमें एक सिंक्रनाइज़ेशन संदर्भ होता है जो मानक से अलग होता है। यदि एक विशेष सिंक्रनाइज़ेशन संदर्भ है, तो कॉलिंग थ्रेड को अवरुद्ध करने से कई बार होने वाले गतिरोध की संभावना बढ़ जाती है। इसलिए, उदाहरण (1-3) से कोड, अगर इसे WinForms UI थ्रेड में निष्पादित किया जाता है, तो गतिरोध पैदा करने की लगभग गारंटी है। मैं "व्यावहारिक रूप से" लिखता हूं क्योंकि एक विकल्प है जब यह ऐसा नहीं है, लेकिन बाद में उस पर और अधिक। ConfigureAwait(false) जोड़ना, (4) के रूप में, गतिरोध से सुरक्षा की 100% गारंटी नहीं देगा। निम्नलिखित इस बात की पुष्टि करने के लिए एक उदाहरण है:

 [7] //   /  . async Task FooAsync() { // Delay   .     . await Task.Delay(5000); //       RestPartOfMethodCode(); } //  ""  ,   ,  WinForms . private void button1_Click(object sender, EventArgs e) { FooAsync() .ConfigureAwait(false) .GetAwaiter() .GetResult(); button1.Text = "new text"; }

लेख "समानांतर कम्प्यूटिंग - यह सभी सिंक्रनाइज़ेशन के बारे में है। कॉन्टेक्स्ट" विभिन्न सिंक्रनाइज़ेशन संदर्भों के बारे में जानकारी प्रदान करता है।

गतिरोध के कारण को समझने के लिए, आपको राज्य मशीन के कोड का विश्लेषण करने की आवश्यकता है जिसमें कॉल को async विधि में परिवर्तित किया गया है, और फिर MS कक्षाओं का कोड। एक Async प्रतीक्षा और उत्पन्न StateMachine लेख इस तरह के एक राज्य मशीन का एक उदाहरण प्रदान करता है।
मैं उदाहरण के लिए उत्पन्न पूर्ण स्रोत कोड नहीं दूंगा (7), ऑटोमेटन, मैं केवल लाइनों को आगे के विश्लेषण के लिए महत्वपूर्ण दिखाऊंगा:

 //  MoveNext. //... //  taskAwaiter    . taskAwaiter = Task.Delay(5000).GetAwaiter(); if(tasAwaiter.IsCompleted != true) { _awaiter = taskAwaiter; _nextState = ...; _builder.AwaitUnsafeOnCompleted<TaskAwaiter, ThisStateMachine>(ref taskAwaiter, ref this); return; }

if एसिंक्रोनस कॉल ( Delay ) अभी तक पूरा नहीं हुआ है और if शाखा को निष्पादित किया जाता है, इसलिए, वर्तमान थ्रेड को मुक्त किया जा सकता है।
कृपया ध्यान दें कि AwaitUnsafeOnCompleted , taskAwaiter एक आंतरिक ( FooAsync सापेक्ष) अतुल्यकालिक कॉल ( Delay ) से प्राप्त होता है।

यदि आप AwaitUnsafeOnCompleted कॉल के पीछे छिपे MS स्रोतों के जंगल में डुबकी AwaitUnsafeOnCompleted हैं, तो, अंत में, हम SynchronizationContextAwaitTaskContinuation class, और इसके आधार वर्ग AwaitTaskContinuation पर आएंगे , जहाँ प्रश्न का उत्तर स्थित है।

इन और संबंधित वर्गों का कोड बल्कि भ्रमित करने वाला है, इसलिए, धारणा को सुविधाजनक बनाने के लिए, मैं अपने आप को एक बहुत ही सरल "एनालॉग" लिखने की अनुमति देता हूं जो उदाहरण (7) में बदल जाता है, लेकिन एक राज्य मशीन के बिना, और टीपीएल के संदर्भ में:

 [8] Task FooAsync() { //  methodCompleted    ,  , //    ,     " ". //    ,   methodCompleted.WaitOne()  , //   SetResult  AsyncTaskMethodBuilder, //       . var methodCompleted = new AutoResetEvent(false); SynchronizationContext current = SynchronizationContext.Current; return Task.Delay(5000).ContinueWith( t=> { if(current == null) { RestPartOfMethodCode(methodCompleted); } else { current.Post(state=>RestPartOfMethodCode(methodCompleted), null); methodCompleted.WaitOne(); } }, TaskScheduler.Current); } // // void RestPartOfMethodCode(AutoResetEvent methodCompleted) // { //      FooAsync. // methodCompleted.Set(); // }

उदाहरण (8) में, इस तथ्य पर ध्यान देना महत्वपूर्ण है कि अगर एक सिंक्रनाइज़ेशन संदर्भ है, तो आंतरिक अतुल्यकालिक कॉल के पूरा होने के बाद आने वाले अतुल्यकालिक विधि के सभी कोड को इस संदर्भ (कॉल current.Post(...) ) के माध्यम से निष्पादित किया जाता है । यह तथ्य गतिरोध का कारण है। उदाहरण के लिए, अगर हम एक WinForms एप्लिकेशन के बारे में बात कर रहे हैं, तो इसमें सिंक्रनाइज़ेशन संदर्भ UI स्ट्रीम के साथ जुड़ा हुआ है। यदि UI थ्रेड ब्लॉक किया गया है, उदाहरण के लिए (7) यह एक कॉल के माध्यम से होता है। .GetResult() , तो एसिंक्रोनस विधि के बाकी कोड को निष्पादित नहीं किया जा सकता है, जिसका अर्थ है कि एसिंक्रोनस विधि पूरी नहीं कर सकती है, और यूआई थ्रेड को जारी नहीं कर सकती है, जो है गतिरोध।

उदाहरण (7) में, FooAsync को कॉल ConfigureAwait(false) माध्यम से ConfigureAwait(false) गया था, लेकिन इससे कोई मदद नहीं मिली। तथ्य यह है कि आपको वास्तव में प्रतीक्षा वस्तु को कॉन्फ़िगर करने की आवश्यकता है जिसे हमारे उदाहरण में AwaitUnsafeOnCompleted को दिया जाएगा, यह Delay कॉल से प्रतीक्षा वस्तु है। दूसरे शब्दों में, इस मामले में, क्लाइंट कोड में ConfigureAwait(false) को कॉल करने का कोई मतलब नहीं है। आप समस्या को हल कर सकते हैं यदि FooAsync विधि का डेवलपर इसे निम्नानुसार बदलता है:

 [9] async Task FooAsync() { await Task.Delay(5000).ConfigureAwait(false); //       RestPartOfMethodCode(); } private void button1_Click(object sender, EventArgs e) { FooAsync().GetAwaiter().GetResult(); button1.Text = "new text"; }

ऊपर, हमने पहले समूह के कोड के साथ उत्पन्न होने वाले जोखिमों की जांच की - ब्लॉकिंग कोड (उदाहरण 1-4)। अब दूसरे समूह के बारे में (उदाहरण 5 और 6) - ताले के बिना एक कोड। इस मामले में, सवाल यह है कि ConfigureAwait(false) लिए कॉल कब उचित है? उदाहरण (7) को पार्स करते समय, हमें पहले ही पता चला कि हमें प्रतीक्षा वस्तु को कॉन्फ़िगर करने की आवश्यकता है जिसके आधार पर निष्पादन की निरंतरता का निर्माण किया जाएगा। यानी कॉन्फ़िगरेशन की आवश्यकता है (यदि आप यह निर्णय लेते हैं) केवल आंतरिक अतुल्यकालिक कॉल के लिए।

किसे दोष देना है?

हमेशा की तरह, सही उत्तर "सब कुछ है।" चलो एमएस से प्रोग्रामर के साथ शुरू करते हैं। एक तरफ, Microsoft डेवलपर्स ने फैसला किया कि, एक सिंक्रनाइज़ेशन संदर्भ की उपस्थिति में, इसके माध्यम से काम किया जाना चाहिए। और यह तर्कसंगत है, अन्यथा इसकी आवश्यकता अभी भी क्यों है। और, जैसा कि मेरा मानना है, उन्हें उम्मीद थी कि "क्लाइंट" कोड के डेवलपर्स मुख्य धागे को अवरुद्ध नहीं करेंगे , खासकर अगर सिंक्रनाइज़ेशन संदर्भ इसे से बंधा हुआ है। दूसरी ओर, उन्होंने "पैर में अपने आप को गोली मारने के लिए" एक बहुत ही सरल उपकरण दिया - यह अवरुद्ध के माध्यम से परिणाम प्राप्त करने के लिए बहुत सरल और सुविधाजनक है .Result/.GetResult , या स्ट्रीम को ब्लॉक करें, कॉल समाप्त होने की प्रतीक्षा कर रहे हैं। यानी एमएस डेवलपर्स ने यह संभव कर दिया है कि उनके पुस्तकालयों का "गलत" (या खतरनाक) उपयोग किसी भी कठिनाइयों का कारण नहीं है।

लेकिन "क्लाइंट" कोड के डेवलपर्स पर दोष है। यह इस तथ्य में शामिल है कि, अक्सर, डेवलपर्स अपने उपकरण को समझने और चेतावनियों की उपेक्षा करने की कोशिश नहीं करते हैं। और यह गलतियों का सीधा रास्ता है।

क्या करें?

नीचे मैं अपनी सिफारिशें देता हूं।

क्लाइंट कोड डेवलपर्स के लिए

ब्लॉकिंग से बचने की पूरी कोशिश करें। दूसरे शब्दों में, विशेष आवश्यकता के बिना सिंक्रोनस और एसिंक्रोनस कोड को न मिलाएं।
यदि आपको एक लॉक करना है, तो यह निर्धारित करें कि कोड को किस वातावरण में निष्पादित किया गया है:
- क्या एक सिंक्रनाइज़ेशन संदर्भ है? यदि हां, तो कौन सा? वह अपने काम में क्या विशेषताएं पैदा करता है?
- यदि कोई सिंक्रनाइज़ेशन संदर्भ नहीं है, तो: लोड क्या होगा? क्या संभावना है कि आपका ब्लॉक पूल से धागे के "रिसाव" का नेतृत्व करेगा? प्रारंभ में बनाए गए थ्रेड्स की संख्या डिफ़ॉल्ट रूप से पर्याप्त होगी, या क्या मुझे अधिक आवंटित करना चाहिए?
यदि कोड अतुल्यकालिक है, तो क्या आपको कॉन्फिगरएविट के माध्यम से एसिंक्रोनस कॉल को कॉन्फ़िगर करने की आवश्यकता है?

प्राप्त सभी सूचनाओं के आधार पर निर्णय लें। आपको अपने कार्यान्वयन दृष्टिकोण पर पुनर्विचार करने की आवश्यकता हो सकती है। शायद ConfigureAwait आपकी मदद करेगा, या शायद आपको इसकी आवश्यकता नहीं है।

पुस्तकालय डेवलपर्स के लिए

यदि आप मानते हैं कि आपके कोड को "सिंक्रोनस" से बुलाया जा सकता है, तो एक सिंक्रोनस एपीआई को लागू करना सुनिश्चित करें। यह वास्तव में तुल्यकालिक होना चाहिए, अर्थात आपको तीसरे पक्ष के पुस्तकालयों के तुल्यकालिक एपीआई का उपयोग करना चाहिए।
ConfigureAwait(true / false) ।

यहाँ, मेरे दृष्टिकोण से, आमतौर पर सिफारिश की तुलना में अधिक सूक्ष्म दृष्टिकोण की आवश्यकता होती है। कई लेखों में कहा गया है कि लाइब्रेरी कोड में, सभी एसिंक्रोनस कॉल्स ConfigureAwait(false) माध्यम से ConfigureAwait(false) किए जाने चाहिए। मैं इससे सहमत नहीं हो सकता। शायद, लेखकों के दृष्टिकोण से, सिंक्रनाइज़ेशन संदर्भ के साथ काम करने के संबंध में "डिफ़ॉल्ट" व्यवहार का चयन करते समय Microsoft के सहयोगियों ने गलत निर्णय लिया। लेकिन वे (एमएस), फिर भी, इस व्यवहार को बदलने के लिए "क्लाइंट" कोड के डेवलपर्स के लिए अवसर छोड़ गए। रणनीति, जब लाइब्रेरी कोड पूरी तरह से ConfigureAwait(false) द्वारा कवर किया जाता है, डिफ़ॉल्ट व्यवहार को बदल देता है, और, अधिक महत्वपूर्ण बात, यह दृष्टिकोण डेवलपर्स को "ग्राहक" पसंद के कोड से वंचित करता है।

मेरा विकल्प यह है कि, एसिंक्रोनस एपीआई को लागू करते समय, प्रत्येक एपीआई विधि में दो अतिरिक्त इनपुट पैरामीटर जोड़ें: CancellationToken token और bool continueOnCapturedContext । और कोड को निम्नानुसार लागू करें:

 public async Task<string> FooAsync( /*  */, CancellationToken token, bool continueOnCapturedContext) { // ... await Task.Delay(30, token).ConfigureAwait(continueOnCapturedContext); // ... return result; }

समन्वित रद्दीकरण की संभावना के लिए पहला पैरामीटर, token , कार्य करता है, जैसा कि आप जानते हैं (पुस्तकालय डेवलपर्स कभी-कभी इस सुविधा की उपेक्षा करते हैं)। दूसरा, continueOnCapturedContext - आपको आंतरिक अतुल्यकालिक कॉल के सिंक्रनाइज़ेशन संदर्भ के साथ सहभागिता को कॉन्फ़िगर करने की अनुमति देता है।

उसी समय, यदि एसिंक्रोनस एपीआई विधि स्वयं एक अन्य अतुल्यकालिक विधि का हिस्सा है, तो "क्लाइंट" कोड यह निर्धारित करने में सक्षम होगा कि उसे सिंक्रोनाइज़ेशन संदर्भ के साथ कैसे इंटरैक्ट करना चाहिए:

 //     : async Task ClientFoo() { // ""  ClientFoo   ,     //   FooAsync   . await FooAsync( /*  */, ancellationToken.None, false); //     . await FooAsync( /*  */, ancellationToken.None, false).ConfigureAwait(false); //... } // ,  . private void button1_Click(object sender, EventArgs e) { FooAsync( /*  */, _source.Token, false).GetAwaiter().GetResult(); button1.Text = "new text"; }

निष्कर्ष में

पूर्वगामी से मुख्य निष्कर्ष निम्नलिखित तीन विचार हैं:

ताले सबसे अधिक बार सभी बुराई की जड़ हैं। यह ताले की उपस्थिति है जो सबसे अच्छे मामले में, प्रदर्शन की गिरावट और संसाधनों के अकुशल उपयोग को, सबसे बुरे में - गतिरोध के लिए नेतृत्व कर सकता है। इससे पहले कि आप ताले का उपयोग करें, विचार करें कि क्या यह आवश्यक है? शायद आपके मामले में स्वीकार्य सिंक्रनाइज़ेशन का एक और तरीका है;
उस टूल को जानें जिसके साथ आप काम कर रहे हैं;
यदि आप पुस्तकालयों को डिज़ाइन करते हैं, तो यह सुनिश्चित करने का प्रयास करें कि उनका सही उपयोग आसान है, लगभग सहज है, और गलत एक जटिलता से भरा है।

मैंने async / प्रतीक्षा के साथ जुड़े जोखिमों और उनकी घटना के कारणों को समझाने के लिए यथासंभव सरल प्रयास किया। और साथ ही, इन समस्याओं को हल करने के अपने दृष्टिकोण को प्रस्तुत किया। मुझे आशा है कि मैं सफल रहा, और सामग्री पाठक के लिए उपयोगी होगी। यह समझने के लिए कि वास्तव में सब कुछ कैसे काम करता है, आपको निश्चित रूप से, स्रोत का संदर्भ देना चाहिए। यह GitHub पर MS रिपॉजिटरी के माध्यम से किया जा सकता है, या इससे भी अधिक सुगमता से MS वेबसाइट के माध्यम से।

पी एस मैं रचनात्मक आलोचना के लिए आभारी रहूंगा।