🆑 💠 🤵🏿 एसिंक्रोनस डीसिन्क्रोनाइज़ेशन: async / प्रतीक्षा में .NET के साथ काम करने में एंटीपैर्टन 🗺️ 🙏🏻 🕗

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

यह पाठ स्टीफन क्लेरी के ब्लॉग से प्रेरित है, एक ऐसा व्यक्ति जो प्रतिस्पर्धा, अतुल्यकालिक, बहुआयामी और अन्य डरावने शब्दों के बारे में सब कुछ जानता है। वह सी # कुकबुक में किताब कॉनएरेबिलिटी के लेखक हैं, जिसने प्रतियोगिता के साथ काम करने के लिए बहुत सारे पैटर्न एकत्र किए हैं।

क्लासिक अतुल्यकालिक गतिरोध

अतुल्यकालिक गतिरोध को समझने के लिए, यह पता लगाने के लायक है कि कौन सा धागा प्रतीक्षित कीवर्ड का उपयोग करके लागू विधि को निष्पादित करता है।

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

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

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

लेकिन क्या होगा अगर, इस विशेष मामले में, यह हमारे लिए महत्वपूर्ण है कि प्रतीक्षा के बाद कोड थ्रेड पूल से किसी भी मुक्त थ्रेड में निष्पादित किया जाता है? आपको ConfigureAwait(false) मंत्र ConfigureAwait(false) का उपयोग करने की आवश्यकता है। continueOnCapturedContext लिए पास किया गया गलत मान ONCapturedContext पैरामीटर सिस्टम को बताता है कि पूल से किसी भी थ्रेड का उपयोग किया जा सकता है। और क्या होता है अगर प्रतीक्षा के साथ विधि निष्पादन के समय कोई भी सिंक्रनाइज़ेशन संदर्भ नहीं था ( SynchronizationContext.Current == null ), उदाहरण के लिए कंसोल एप्लिकेशन में। इस मामले में, हमारे पास उस थ्रेड पर कोई प्रतिबंध नहीं है जिसमें प्रतीक्षा के बाद कोड निष्पादित किया जाना चाहिए और सिस्टम पूल से पहला थ्रेड ले जाएगा, जैसा कि ConfigureAwait(false) के मामले में है।

तो एक अतुल्यकालिक गतिरोध क्या है?

WPF और WinForms में गतिरोध

WPF और WinForms अनुप्रयोगों के बीच का अंतर बहुत ही सिंक्रनाइज़ेशन संदर्भ है। WPF और WinForms के सिंक्रनाइज़ेशन संदर्भ में एक विशेष थ्रेड है - उपयोगकर्ता इंटरफ़ेस थ्रेड। SynchronizationContext प्रति एक UI थ्रेड है और केवल इस थ्रेड से उपयोगकर्ता इंटरफ़ेस तत्व इंटरैक्ट कर सकते हैं। डिफ़ॉल्ट रूप से, यूआई थ्रेड में काम करना शुरू करने वाला कोड इसमें एक अतुल्यकालिक ऑपरेशन के बाद ऑपरेशन फिर से शुरू करता है।

अब एक उदाहरण देखते हैं:

 private void Button_Click(object sender, System.Windows.RoutedEventArgs e) { StartWork().Wait(); } private async Task StartWork() { await Task.Delay(100); var s = "Just to illustrate the instruction following await"; }

जब आप StartWork().Wait() कहते हैं तो क्या होता है StartWork().Wait() :

कॉलिंग थ्रेड (और यह यूजर इंटरफेस थ्रेड है) StartWork विधि में जाएगा और StartWork लिए जाना जाएगा। await Task.Delay(100) निर्देश।
UI थ्रेड अतुल्यकालिक Task.Delay(100) शुरू कर Task.Delay(100) ऑपरेशन, और यह Button_Click विधि पर नियंत्रण Button_Click , और वहां Task वर्ग की Wait() विधि इसके लिए इंतजार करेगी। जब Wait() विधि कहा जाता है, तो यूआई धागा एसिंक्रोनस ऑपरेशन के अंत तक ब्लॉक हो जाएगा, और हम उम्मीद करते हैं कि जैसे ही यह पूरा हो जाएगा, यूआई थ्रेड तुरंत निष्पादन उठाएगा और कोड के साथ आगे बढ़ेगा, हालांकि, सब कुछ गलत होगा।
जैसे ही Task.Delay(100) पूरा हो गया है, UI थ्रेड को सबसे पहले StartWork() विधि को निष्पादित करना जारी रखना होगा और इसके लिए इसे ठीक उसी थ्रेड की आवश्यकता है जिसमें निष्पादन प्रारंभ हुआ था। लेकिन UI थ्रेड अब ऑपरेशन के परिणाम की प्रतीक्षा कर रहा है।
StartWork() : StartWork() निष्पादन जारी नहीं रख सकता है और परिणाम लौटा सकता है, और Button_Click उसी परिणाम की प्रतीक्षा कर रहा है, और इस तथ्य के कारण कि उपयोगकर्ता इंटरफ़ेस थ्रेड में निष्पादन शुरू हो गया है, एप्लिकेशन को बस काम जारी रखने का मौका दिए बिना लटका हुआ है।

इस स्थिति को काफी सरलता से कॉल को Task.Delay(100) जा सकता है। Task.Delay(100) को Task.Delay(100).ConfigureAwait(false) को कॉल करें।

 private void Button_Click(object sender, System.Windows.RoutedEventArgs e) { StartWork().Wait(); } private async Task StartWork() { await Task.Delay(100).ConfigureAwait(false); var s = "Just to illustrate the instruction following await"; }

यह कोड डेडलॉक के बिना काम करेगा, क्योंकि अब ब्लॉक यूआई थ्रेड के बजाय पूल से एक धागे का उपयोग StartWork() विधि को पूरा करने के लिए किया जा सकता है। स्टीफन क्लेरी अपने ब्लॉग में सभी "पुस्तकालय विधियों" में ConfigureAwait(false) का उपयोग करने की सलाह देते हैं, लेकिन विशेष रूप से जोर देते हैं कि गतिरोध का इलाज करने के लिए कन्फिगरएविट ConfigureAwait(false) का उपयोग ConfigureAwait(false) एक अच्छा अभ्यास नहीं है। इसके बजाय, वह Wait() , Result , GetAwaiter().GetResult() और यदि संभव हो तो तथाकथित Async सभी तरह के सिद्धांत का उपयोग करने के लिए सभी विधियों को GetAwaiter().GetResult() करें।

ASP.NET में गतिरोध

ASP.NET का एक सिंक्रनाइज़ेशन संदर्भ भी है, लेकिन इसकी कुछ अलग सीमाएँ हैं। यह आपको एक समय में केवल एक थ्रेड प्रति अनुरोध का उपयोग करने की अनुमति देता है और यह भी आवश्यक है कि प्रतीक्षा के बाद कोड को उसी थ्रेड में निष्पादित किया जाए जो प्रतीक्षा से पहले कोड है।

एक उदाहरण:

 public class HomeController : Controller { public ActionResult Deadlock() { StartWork().Wait(); return View(); } private async Task StartWork() { await Task.Delay(100); var s = "Just to illustrate the code following await"; } }

StartWork().Wait() कॉल के समय से यह कोड एक गतिरोध का कारण भी बनेगा StartWork().Wait() केवल अनुमत थ्रेड को ब्लॉक किया जाएगा और StartWork() ऑपरेशन के StartWork() प्रतीक्षा करेगा, और यह कभी भी समाप्त नहीं होगा, क्योंकि थ्रेड जिसमें निष्पादन जारी रहना चाहिए व्यस्त है। उम्मीद।

यह सब एक ही ConfigureAwait(false) द्वारा तय किया गया है।

ASP.NET कोर में गतिरोध (वास्तव में नहीं)

अब कोड को ASP.NET कोर के लिए प्रोजेक्ट में ASP.NET के उदाहरण से चलाने की कोशिश करते हैं। यदि हम ऐसा करते हैं, तो हम देखेंगे कि कोई गतिरोध नहीं होगा। ऐसा इसलिए है क्योंकि ASP.NET Core में सिंक्रोनाइज़ेशन संदर्भ नहीं है । बहुत बढ़िया! और अब आप अवरुद्ध कॉल के साथ कोड को कवर कर सकते हैं और डेडलॉक से डर नहीं सकते? कड़ाई से बोलते हुए, हां, लेकिन याद रखें कि यह प्रतीक्षा करते समय धागा सो जाता है, अर्थात, धागा संसाधनों का उपभोग करता है, लेकिन कोई उपयोगी काम नहीं करता है।

याद रखें कि ब्लॉकिंग कॉल का उपयोग अतुल्यकालिक प्रोग्रामिंग के सभी लाभों को सिंक्रोनस में बदल देता है । हां, कभी-कभी Wait() का उपयोग किए बिना Wait() यह प्रोग्राम लिखने के लिए काम नहीं करेगा, लेकिन इसका कारण गंभीर होना चाहिए।

Task.Run () का गलत उपयोग

Task.Run() विधि एक नए धागे में संचालन शुरू करने के लिए बनाई गई थी। जैसा कि एक TAP पैटर्न में लिखी गई विधि है, यह Task या Task<T> लौटाता है और जिन लोगों को पहली बार async / इंतजार का सामना करना पड़ता है, उनके पास Task.Run() में सिंक्रोनस कोड को लपेटने की बहुत इच्छा होती है और इस पद्धति के परिणाम को eutite करते हैं। कोड अतुल्यकालिक प्रतीत हो रहा था, लेकिन वास्तव में, कुछ भी नहीं बदला है। आइए देखते हैं कि Task.Run() इस उपयोग के साथ क्या होता है।

एक उदाहरण:

 private static async Task ExecuteOperation() { Console.WriteLine($"Before: {Thread.CurrentThread.ManagedThreadId}"); await Task.Run(() => { Console.WriteLine($"Inside before sleep: {Thread.CurrentThread.ManagedThreadId}"); Thread.Sleep(1000); Console.WriteLine($"Inside after sleep: {Thread.CurrentThread.ManagedThreadId}"); }); Console.WriteLine($"After: {Thread.CurrentThread.ManagedThreadId}"); }

इस कोड का परिणाम होगा:

 Before: 1 Inside before sleep: 3 Inside after sleep: 3 After: 3

यहाँ Thread.Sleep(1000) कुछ प्रकार का सिंक्रोनस ऑपरेशन है जिसे पूरा करने के लिए थ्रेड की आवश्यकता होती है। मान लीजिए कि हम अपने समाधान को अतुल्यकालिक बनाना चाहते हैं और ताकि इस ऑपरेशन को Task.Run() किया जा सके, हमने इसे Task.Run() में लपेट दिया।

जैसे ही कोड Task.Run() विधि पर पहुंचता है, थ्रेड पूल से एक और धागा लिया जाता है और जो कोड हमने Task.Run() को पास किया है, उसमें निष्पादित होता है। पुराना धागा, जैसा कि एक सभ्य धागा है, पूल में लौटता है और काम करने के लिए फिर से बुलाए जाने का इंतजार करता है। नया थ्रेड संचारित कोड को निष्पादित करता है, सिंक्रोनस ऑपरेशन तक पहुंचता है, सिंक्रोनाइज़ करता है, इसे निष्पादित करता है (ऑपरेशन पूरा होने तक इंतजार करता है) और कोड के साथ आगे बढ़ता है। दूसरे शब्दों में, ऑपरेशन सिंक्रोनस रहा: हम, पहले की तरह, सिंक्रोनस ऑपरेशन के निष्पादन के दौरान स्ट्रीम का उपयोग करते हैं। अंतर केवल इतना है कि हमने Task.Run() को ExecuteOperation() करने में समय बिताया है। कॉल करते समय। Task.Run() और Task.Run() वापस ExecuteOperation() । सब कुछ थोड़ा खराब हो गया है।

यह समझा जाना चाहिए कि इस तथ्य के बावजूद कि Inside after sleep: 3 की पंक्तियों में Inside after sleep: 3 और After: 3 हम धारा के एक ही ईद को देखते हैं, निष्पादन का संदर्भ इन स्थानों में पूरी तरह से अलग है। ASP.NET बस हमसे अधिक चालाक है और Task.Run() के अंदर कोड से संदर्भ स्विच करते समय संसाधनों को बचाने की कोशिश करता है। Task.Run() से बाहरी कोड। यहां उन्होंने कम से कम निष्पादन के प्रवाह को नहीं बदलने का फैसला किया।

ऐसे मामलों में, इसका कोई मतलब नहीं है कि Task.Run() का उपयोग करें। इसके बजाय, क्लैरी सभी ऑपरेशनों को अतुल्यकालिक बनाने की सलाह देती है , अर्थात, हमारे मामले में, Thread.Sleep(1000) को Task.Delay(1000) साथ Task.Delay(1000) , लेकिन यह, निश्चित रूप से, हमेशा संभव नहीं है। जब हम तीसरे पक्ष के पुस्तकालयों का उपयोग करते हैं तो क्या करें जो हम फिर से लिखना नहीं चाहते और अंत तक अतुल्यकालिक बना सकते हैं, लेकिन एक कारण या किसी अन्य के लिए हमें async विधि की आवश्यकता है? टास्क में विक्रेता विधियों के परिणाम को लपेटने के लिए Task.FromResult() का उपयोग करना बेहतर है। यह, निश्चित रूप से, कोड को अतुल्यकालिक नहीं बनाएगा, लेकिन हम कम से कम संदर्भ स्विचिंग पर बचत करेंगे।

तो फिर Task.Run () का उपयोग क्यों करें? उत्तर सरल है: सीपीयू-बाउंड संचालन के लिए, जब आपको यूआई की जवाबदेही बनाए रखने या गणना को समानांतर करने की आवश्यकता होती है। यहां यह कहा जाना चाहिए कि सीपीयू-बाउंड ऑपरेशन प्रकृति में समकालिक हैं। यह एक अतुल्यकालिक शैली में सिंक्रोनस ऑपरेशन लॉन्च करना था जिसे Task.Run() का आविष्कार किया गया था।

Async शून्य का दुरुपयोग

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

आप परिणाम के लिए इंतजार नहीं कर सकते
कोशिश-कैच के माध्यम से अपवाद हैंडलिंग समर्थित नहीं है।
Task.WhenAll() , Task.WhenAny() और अन्य समान तरीकों के माध्यम से कॉल को जोड़ना असंभव है।

इन सभी कारणों में से, सबसे दिलचस्प बिंदु अपवादों की हैंडलिंग है। तथ्य यह है कि Task या Task<T> वापस करने वाले एसिंक्स तरीकों में, अपवाद को Task ऑब्जेक्ट में पकड़ा और लपेटा जाता है, जिसे बाद में कॉलिंग विधि में पास किया जाएगा। अपने एमएसडीएन लेख में, क्लैरी लिखती है कि चूंकि एसिंक्स-शून्य विधियों में कोई वापसी मूल्य नहीं है, इसलिए अपवादों को लपेटने के लिए कुछ भी नहीं है और उन्हें सीधे सिंक्रनाइज़ेशन के संदर्भ में फेंक दिया जाता है। परिणाम एक अनहेल्दी अपवाद है जिसकी वजह से प्रक्रिया क्रैश हो जाती है, समय रहते, शायद, कंसोल को एक त्रुटि लिखते हैं। आप AppDomain.UnhandledException इवेंट की सदस्यता लेकर ऐसे अपवाद प्राप्त कर सकते हैं और आरक्षित कर सकते हैं, लेकिन आप इस ईवेंट के हैंडलर में भी प्रक्रिया क्रैश को रोक नहीं पाएंगे। यह व्यवहार केवल ईवेंट हैंडलर के लिए विशिष्ट है, लेकिन सामान्य विधि के लिए नहीं, जिससे हम कोशिश-कैच के माध्यम से मानक अपवाद से निपटने की संभावना की उम्मीद करते हैं।

उदाहरण के लिए, यदि आप ASP.NET कोर अनुप्रयोग में इस तरह लिखते हैं, तो प्रक्रिया को गिरने की गारंटी है:

 public IActionResult ThrowInAsyncVoid() { ThrowAsynchronously(); return View(); } private async void ThrowAsynchronously() { throw new Exception("Obviously, something happened"); }

लेकिन यह ThrowAsynchronously तरीके के रिटर्न प्रकार को Task करने के लिए बदल रहा है (प्रतीक्षा कीवर्ड को भी जोड़े बिना) और अपवाद को मानक ASP.NET कोर त्रुटि हैंडलर द्वारा पकड़ा जाएगा, और निष्पादन के बावजूद प्रक्रिया जारी रहेगी।

Async-void तरीकों से सावधान रहें - वे आपको प्रक्रिया में डाल सकते हैं।

एक पंक्ति विधि में प्रतीक्षा करें

पिछले एंटीपार्टर्न पिछले वाले की तरह डरावना नहीं है। लब्बोलुआब यह है कि यह async / वेट का उपयोग करने के लिए कोई मतलब नहीं है, उदाहरण के लिए, बस एक और async विधि के परिणाम को आगे बढ़ाएं, उपयोग करने में वेट का उपयोग करने के संभावित अपवाद के साथ।

इस कोड के बजाय:

 public async Task MyMethodAsync() { await Task.Delay(1000); }

यह पूरी तरह से संभव होगा (और अधिमानतः) लिखने के लिए:

 public Task MyMethodAsync() { return Task.Delay(1000); }

यह काम क्यों करता है? क्योंकि प्रतीक्षित कीवर्ड टास्क जैसी वस्तुओं पर लागू किया जा सकता है, न कि एसिंक्स कीवर्ड के साथ चिह्नित तरीकों पर। बदले में, async कीवर्ड बस संकलक को बताता है कि इस विधि को एक राज्य मशीन पर तैनात करने की आवश्यकता है, और सभी लौटे मानों को Task में लपेटा जाना चाहिए (या किसी अन्य टास्क-जैसे ऑब्जेक्ट में)।

दूसरे शब्दों में, विधि के पहले संस्करण का परिणाम Task , जो Task लिए इंतजार करते Task.Delay(1000) Completed हो जाएगा। ।

जैसा कि आप देख सकते हैं, दोनों संस्करण समतुल्य हैं, लेकिन एक ही समय में, अतुल्यकालिक "सुपर किट" बनाने के लिए पहले अधिक संसाधनों की आवश्यकता होती है।

एलेक्स डेविस लिखते हैं कि एसिंक्रोनस विधि को सीधे लागू करने की लागत तुल्यकालिक विधि को लागू करने की लागत से दस गुना हो सकती है , इसलिए इसके लिए प्रयास करने के लिए कुछ है।

युपीडी:
जैसा कि टिप्पणियां ठीक से इंगित करती हैं, सिंगल-लाइन विधियों से async / प्रतीक्षा करने के लिए नकारात्मक प्रभाव पड़ता है। उदाहरण के लिए, अपवाद फेंकते समय, टास्क को फेंकने वाली विधि स्टैक में दिखाई नहीं देगी। इसलिए, डिफ़ॉल्ट रूप से चूक को हटाने की अनुशंसा नहीं की जाती है । पार्सिंग के साथ क्लेरी की पोस्ट ।

एसिंक्रोनस डीसिन्क्रोनाइज़ेशन: async / प्रतीक्षा में .NET के साथ काम करने में एंटीपैर्टन