अतुल्यकालिक प्रोग्रामिंग - async प्रदर्शन: async और इंतजार की लागत को समझते हैं

यह लेख काफी प्राचीन है, लेकिन इसकी प्रासंगिकता नहीं खोई है। जब यह async / प्रतीक्षा की बात आती है, तो इसके लिए एक लिंक आमतौर पर दिखाई देता है। मुझे रूसी में अनुवाद नहीं मिला, मैंने किसी ऐसे व्यक्ति की मदद करने का फैसला किया जो धाराप्रवाह नहीं है।

असिंक्रोनस प्रोग्रामिंग लंबे समय से सबसे अधिक अनुभवी डेवलपर्स का राज्य है, जो मसोचवाद की लालसा के साथ है - जिनके पास निष्पादन के गैर-रैखिक प्रवाह में कॉलबैक से कॉलबैक के बारे में सोचने के लिए पर्याप्त खाली समय, झुकाव और मानसिक क्षमता थी। Microsoft .NET फ्रेमवर्क 4.5 के आगमन के साथ, C # और Visual Basic ने हम सभी को अतुल्यकालिक लाया है, इसलिए केवल मृत्युदाता अब अतुल्यकालिक तरीके लगभग समान रूप से आसानी से लिख सकते हैं। कॉलबैक की अब आवश्यकता नहीं है। एक सिंक्रनाइज़ेशन संदर्भ से दूसरे में कोई और अधिक स्पष्ट मार्शिंग कोड नहीं। निष्पादन परिणाम या अपवाद कैसे चलते हैं, इसके बारे में अधिक चिंता नहीं है। असिंक्रोनस कोड विकसित करने की सुविधा के लिए प्रोग्रामिंग भाषाओं के साधनों को विकृत करने वाली ट्रिक्स की कोई आवश्यकता नहीं है। संक्षेप में, अधिक परेशानी और सिरदर्द नहीं है।

बेशक, हालांकि अब एसिंक्रोनस तरीके लिखना शुरू करना आसान है (इस MSDN मैगज़ीन [ OCTOBER 2011] में एरिक लिपर्ट और मैड्स टॉर्गेरेन के लेख देखें), इसे सही ढंग से करने के लिए समझ की आवश्यकता होती है। हुड के नीचे क्या होता है। हर बार जब कोई भाषा या पुस्तकालय अमूर्तता के स्तर को बढ़ाता है जो एक डेवलपर उपयोग कर सकता है, तो यह अनिवार्य रूप से छिपी हुई लागत के साथ होता है जो उत्पादकता को कम करता है। कई मामलों में, ये लागत नगण्य हैं, इसलिए अधिकांश प्रोग्रामर द्वारा उन्हें ज्यादातर मामलों में उपेक्षित किया जा सकता है। हालांकि, उन्नत डेवलपर्स को पूरी तरह से समझना चाहिए कि आवश्यक उपाय करने और संभावित समस्याओं को हल करने के लिए क्या लागतें मौजूद हैं यदि वे स्वयं प्रकट होते हैं। C # और Visual Basic में एसिंक्रोनस प्रोग्रामिंग टूल का उपयोग करते समय यह आवश्यक है।

इस लेख में, मैं एसिंक्रोनस विधियों के इनपुट और आउटपुट का वर्णन करूंगा, यह बताऊंगा कि एसिंक्रोनस विधियों को कैसे लागू किया जाता है, और कुछ छोटी लागतों पर चर्चा करें। ध्यान दें कि यह पठनीय कोड को किसी ऐसी चीज़ में विकृत करने की अनुशंसा नहीं है जिसे बनाए रखना मुश्किल है, जिसे माइक्रोपोटिमाइजेशन और प्रदर्शन के नाम पर किया जा सकता है। यह सिर्फ ज्ञान है जो उन समस्याओं का निदान करने में मदद करेगा जो आपके सामने आ सकती हैं, और इन समस्याओं को दूर करने के लिए उपकरणों का एक सेट। इसके अलावा, यह आलेख .NET फ्रेमवर्क संस्करण 4.5 पूर्वावलोकन पर आधारित है, और शायद अंतिम रिलीज में विशिष्ट कार्यान्वयन विवरण बदल सकते हैं।

एक आरामदायक सोच वाला मॉडल प्राप्त करें

दशकों से, प्रोग्रामर उत्पादक अनुप्रयोगों को विकसित करने के लिए उच्च स्तरीय प्रोग्रामिंग भाषाओं C #, Visual Basic, F # और C ++ का उपयोग कर रहे हैं। इस अनुभव ने प्रोग्रामर को विभिन्न कार्यों की लागतों का मूल्यांकन करने और सर्वोत्तम विकास तकनीकों के बारे में ज्ञान प्राप्त करने की अनुमति दी। उदाहरण के लिए, ज्यादातर मामलों में, एक तुल्यकालिक विधि को लागू करना अपेक्षाकृत किफायती है, खासकर यदि कंपाइलर कॉल किए गए विधि की सामग्री को सीधे कॉल बिंदु में एम्बेड कर सकता है। इसलिए, डेवलपर्स कॉल की संख्या बढ़ाने के नकारात्मक परिणामों के बारे में चिंता किए बिना, कोड को छोटे, आसानी से बनाए रखने के तरीकों में तोड़ने के आदी हैं। इन प्रोग्रामर्स का सोच मॉडल विधि कॉल को संभालने के लिए डिज़ाइन किया गया है।

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

अधिक तरीके, कम कॉल

सिंक्रोनस कोड के साथ काम करते समय, खाली सामग्री के साथ चलने के तरीके व्यावहारिक रूप से बेकार हैं। अतुल्यकालिक विधियों के लिए, यह मामला नहीं है। इस अतुल्यकालिक विधि पर विचार करें, जिसमें एक निर्देश शामिल है (और जो प्रतीक्षा विवरण की कमी के कारण निष्पादित किया जाएगा:

public static async Task SimpleBodyAsync() { Console.WriteLine("Hello, Async World!"); } 

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

चित्रा 1 अतुल्यकालिक विधि टेम्पलेट

 [DebuggerStepThrough] public static Task SimpleBodyAsync() { <SimpleBodyAsync>d__0 d__ = new <SimpleBodyAsync>d__0(); d__.<>t__builder = AsyncTaskMethodBuilder.Create(); d__.MoveNext(); return d__.<>t__builder.Task; } [CompilerGenerated] [StructLayout(LayoutKind.Sequential)] private struct <SimpleBodyAsync>d__0 : <>t__IStateMachine { private int <>1__state; public AsyncTaskMethodBuilder <>t__builder; public Action <>t__MoveNextDelegate; public void MoveNext() { try { if (this.<>1__state == -1) return; Console.WriteLine("Hello, Async World!"); } catch (Exception e) { this.<>1__state = -1; this.<>t__builder.SetException(e); return; } this.<>1__state = -1; this.<>t__builder.SetResult(); } ... } 

जब आप आश्चर्य करते हैं कि अतुल्यकालिक तरीकों की लागत कितनी है, तो इस पैटर्न को याद रखें। मूलाधार में इस JIT विधि को एम्बेड करने के संभावित प्रयास को रोकने के लिए MoveNext विधि में कोशिश / कैच ब्लॉक की आवश्यकता है, इसलिए कम से कम हमें विधि को कॉल करने की लागत मिलती है, जबकि सिंक्रोनस विधि का उपयोग करते समय, सबसे अधिक संभावना है कि यह कॉल प्रदान नहीं की जाएगी (बशर्ते कि न्यूनतर सामग्री)। हम फ्रेमवर्क प्रक्रियाओं (उदाहरण के लिए, SetResult) के लिए कई कॉल प्राप्त करेंगे। साथ ही राज्य मशीन ऑब्जेक्ट के क्षेत्रों में कई लेखन कार्य करते हैं। बेशक, हमें कंसोल की लागतों के साथ इन सभी लागतों की तुलना करने की आवश्यकता है। लाइटलाइन, जो प्रबल होने की संभावना है (उनमें लॉकिंग, आई / ओ, आदि की लागत शामिल हैं) पर्यावरण के लिए आपके द्वारा किए गए अनुकूलन पर ध्यान दें। उदाहरण के लिए, एक राज्य मशीन की एक वस्तु को एक संरचना (संरचना) के रूप में लागू किया जाता है। इस संरचना को प्रबंधित हीप में बॉक्स किया जाएगा, यदि विधि को निष्पादन की आवश्यकता है, ऑपरेशन के समाप्त होने की प्रतीक्षा कर रहे हैं, और इस सरल विधि में ऐसा कभी नहीं होगा। तो इस अतुल्यकालिक विधि के पैटर्न को ढेर से मेमोरी आवंटन की आवश्यकता नहीं होगी। कंपाइलर और रनटाइम मेमोरी आवंटन संचालन की संख्या को कम करने की कोशिश करेगा।

जब Async का उपयोग नहीं करना है

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

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

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

मेमोरीस्ट्रीम के रूप में इस प्रकार के कार्यान्वयन पर विचार करें। MemoryStream को स्ट्रीम से विरासत में मिला है, और .NET 4.5 में लागू किए गए नए तरीकों को फिर से परिभाषित करता है: मेमोरी-विशिष्ट कोड अनुकूलन प्रदान करने के लिए ReadAsync, WriteAsync और FlushAsync। चूंकि रीड ऑपरेशन मेमोरी में स्थित एक बफर से किया जाता है, अर्थात यह वास्तव में मेमोरी क्षेत्र की एक प्रति है, सबसे अच्छा प्रदर्शन होगा यदि रीडएस्पुन्स को सिंक्रोनस मोड में निष्पादित किया जाता है। एक अतुल्यकालिक विधि में इसका कार्यान्वयन इस तरह दिख सकता है:

 public override async Task<int> ReadAsync(byte [] buffer, int offset, int count, CancellationToken cancellationToken) { cancellationToken.ThrowIfCancellationRequested(); return this.Read(buffer, offset, count); } 

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

 byte [] buffer = new byte[0x1000]; int numRead; while((numRead = await source.ReadAsync(buffer, 0, buffer.Length)) > 0) { await source.WriteAsync(buffer, 0, numRead); } 

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

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

चित्र 2 कार्य निर्माण का अनुकूलन

 private Task<int> m_lastTask; public override Task<int> ReadAsync(byte [] buffer, int offset, int count, CancellationToken cancellationToken) { if (cancellationToken.IsCancellationRequested) { var tcs = new TaskCompletionSource<int>(); tcs.SetCanceled(); return tcs.Task; } try { int numRead = this.Read(buffer, offset, count); return m_lastTask != null && numRead == m_lastTask.Result ? m_lastTask : (m_lastTask = Task.FromResult(numRead)); } catch(Exception e) { var tcs = new TaskCompletionSource<int>(); tcs.SetException(e); return tcs.Task; } } 

यदि आवश्यक हो तो टास्क ऑब्जेक्ट के अनावश्यक निर्माण को समाप्त करके एक समान अनुकूलन विधि का उपयोग किया जा सकता है। एक विधि पर विचार करें जो एक वेब पेज की सामग्री को पुनः प्राप्त करने और भविष्य के संदर्भ के लिए इसे कैश करने के लिए डिज़ाइन किया गया है। एक अतुल्यकालिक विधि के रूप में, इसे निम्नानुसार लिखा जा सकता है (.NET 4.5 के लिए नई System.Net.Http.dll लाइब्रेरी का उपयोग कर):

 private static ConcurrentDictionary<string,string> s_urlToContents; public static async Task<string> GetContentsAsync(string url) { string contents; if (!s_urlToContents.TryGetValue(url, out contents)) { var response = await new HttpClient().GetAsync(url); contents = response.EnsureSuccessStatusCode().Content.ReadAsString(); s_urlToContents.TryAdd(url, contents); } return contents; } 

यह एक अग्रभाग कार्यान्वयन है। और GetContentsAsync कॉल के लिए जो कैश में डेटा नहीं ढूंढते हैं, नेटवर्क पर डेटा प्राप्त करने की लागत की तुलना में एक नया टास्क ऑब्जेक्ट बनाने के ओवरहेड की उपेक्षा की जा सकती है। हालांकि, कैश से डेटा प्राप्त करने के मामले में, ये लागत महत्वपूर्ण हो जाती हैं यदि आप बस स्थानीय डेटा को लपेटते हैं और उपलब्ध कराते हैं।

इन लागतों को समाप्त करने के लिए (यदि उच्च प्रदर्शन को प्राप्त करना आवश्यक है), तो आप विधि को फिर से लिख सकते हैं जैसा कि चित्र 3 में दिखाया गया है। अब हमारे पास दो विधियाँ हैं: एक तुल्यकालिक सार्वजनिक विधि और एक अतुल्यकालिक निजी विधि, जिसके लिए सार्वजनिक प्रतिनिधि। शब्दकोश संग्रह अब बनाई गई टास्क ऑब्जेक्ट्स को कैश करता है, उनकी सामग्री को नहीं, इसलिए भविष्य में उस पृष्ठ की सामग्री को पुनः प्राप्त करने का प्रयास करता है जो पहले सफलतापूर्वक प्राप्त किया गया था, मौजूदा टास्क ऑब्जेक्ट को वापस करने के लिए केवल संग्रह तक पहुंचकर प्रदर्शन किया जा सकता है। अंदर, आप टास्क ऑब्जेक्ट के ContinueWith तरीकों का उपयोग करके लाभ उठा सकते हैं, जो हमें संग्रह में निष्पादित ऑब्जेक्ट को सहेजने की अनुमति देता है - यदि पृष्ठ लोड करने में सफल रहा। बेशक, यह कोड अधिक जटिल है और प्रदर्शन का अनुकूलन करते समय हमेशा की तरह बहुत अधिक विकास और समर्थन की आवश्यकता होती है: आप इसे तब तक लिखना नहीं चाहते हैं जब तक कि प्रदर्शन परीक्षण यह न दिखा दे कि ये जटिलताएं इसके सुधार की ओर ले जाती हैं, जो प्रभावशाली और स्पष्ट है। क्या सुधार वास्तव में आवेदन की विधि पर निर्भर करेगा। आप एक परीक्षण सूट ले सकते हैं जो सामान्य उपयोग के मामलों का अनुकरण करता है और यह निर्धारित करने के लिए परिणामों का मूल्यांकन करता है कि क्या खेल मोमबत्ती के लायक है।

चित्रा 3 मैन्युअल रूप से कैशिंग कार्यों

 private static ConcurrentDictionary<string,Task<string>> s_urlToContents; public static Task<string> GetContentsAsync(string url) { Task<string> contents; if (!s_urlToContents.TryGetValue(url, out contents)) { contents = GetContentsInternalAsync(url); contents.ContinueWith(delegate { s_urlToContents.TryAdd(url, contents); }, CancellationToken.None, TaskContinuationOptions.OnlyOnRanToCompletion | TaskContinuatOptions.ExecuteSynchronously, TaskScheduler.Default); } return contents; } private static async Task<string> GetContentsInternalAsync(string url) { var response = await new HttpClient().GetAsync(url); return response.EnsureSuccessStatusCode().Content.ReadAsString(); } 

टास्क ऑब्जेक्ट्स से जुड़ी एक अन्य अनुकूलन विधि यह निर्धारित करने के लिए है कि क्या अतुल्यकालिक विधि से ऐसी वस्तु को वापस करना है। C # और Visual Basic दोनों अतुल्यकालिक विधियों का समर्थन करते हैं जो एक शून्य मान (शून्य) लौटाते हैं, और वे टास्क ऑब्जेक्ट्स बिल्कुल भी नहीं बनाते हैं। पुस्तकालयों में अतुल्यकालिक तरीकों को हमेशा टास्क और टास्क को वापस करना चाहिए, क्योंकि पुस्तकालय को डिजाइन करते समय आप यह नहीं जान सकते कि उनका उपयोग पूरा होने के इंतजार में नहीं किया जाएगा। हालांकि, अनुप्रयोगों को विकसित करते समय, शून्य को वापस करने वाले तरीके अपना स्थान पा सकते हैं। इस तरह के तरीकों के अस्तित्व का मुख्य कारण मौजूदा ईवेंट-चालित वातावरण, जैसे ASP.NET और Windows प्रस्तुति फाउंडेशन (WPF) प्रदान करना है। एस्किंट और वेट का उपयोग करते हुए, इन तरीकों से बटन हैंडलर्स, पेज लोड इवेंट आदि को लागू करना आसान हो जाता है। यदि आप शून्य के साथ एक अतुल्यकालिक विधि का उपयोग करने का इरादा रखते हैं, तो अपवादों को संभालने के साथ सावधान रहें: इसमें से अपवाद किसी भी सिंक्रोनाइज़ेशन कॉन्टेक्स्ट में पॉप अप करेंगे जो उस समय विधि को कहा जाता था।

संदर्भ मत भूलना

.NET फ्रेमवर्क में कई अलग-अलग संदर्भ हैं: LogicalCallContext, SynchronizationContext, HostExecutionContext, SecurityContext, ExecutionContext और अन्य (उनकी विशाल राशि सुझाव दे सकती है कि नए संदर्भ बनाने के लिए वित्तीय रूप से प्रेरित थे, लेकिन मुझे यह ज़रूर पता है)। इनमें से कुछ संदर्भ न केवल कार्यक्षमता के मामले में, बल्कि प्रदर्शन में भी अतुल्यकालिक तरीकों को दृढ़ता से प्रभावित करते हैं।

सिंक्रोनाइज़ेशन कॉन्टेक्स्ट सिंक्रोनाइज़ेशन कॉन्टेक्स्ट एसिंक्रोनस विधियों के लिए एक महत्वपूर्ण भूमिका निभाता है। एक "सिंक्रनाइज़ेशन संदर्भ" केवल यह सुनिश्चित करने के लिए एक अमूर्त है कि एक विशेष पुस्तकालय या पर्यावरण की बारीकियों के साथ एक प्रतिनिधि मंगलाचरण। उदाहरण के लिए, WPF में डिस्पैचर के लिए एक यूजर इंटरफेस (UI) थ्रेड का प्रतिनिधित्व करने के लिए DispatcherSynchronizationContext है: इस सिंक्रोनाइज़ेशन के संदर्भ में एक प्रतिनिधि भेजने से यह प्रतिनिधि डिस्पैचर द्वारा उसके थ्रेड में निष्पादन के लिए कतारबद्ध हो जाता है। ASP.NET एक AspNetSynchronizationContext प्रदान करता है जो यह सुनिश्चित करने के लिए उपयोग किया जाता है कि ASP.NET अनुरोध को संसाधित करने में शामिल अतुल्यकालिक संचालन क्रमिक रूप से निष्पादित होने की गारंटी है और सही HttpContext राज्य के लिए बाध्य है। खैर, आदि। सामान्य तौर पर, .NET फ्रेमवर्क में SynchronizationContext के लगभग 10 विशेषज्ञ हैं, कुछ खुले, कुछ आंतरिक।

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

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

 byte [] buffer = new byte[0x1000]; int numRead; while((numRead = await source.ReadAsync(buffer, 0, buffer.Length)) > 0) { await source.WriteAsync(buffer, 0, numRead); } 

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

 byte [] buffer = new byte[0x1000]; int numRead; while((numRead = await source.ReadAsync(buffer, 0, buffer.Length).ConfigureAwait(false)) > 0) { await source.WriteAsync(buffer, 0, numRead).ConfigureAwait(false); } 

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

प्रदर्शन के अलावा, एक और कारण है कि आपको पुस्तकालयों को विकसित करते समय कन्फिगरएवाइट का उपयोग करने की आवश्यकता है। कल्पना करें कि CopyStreamToStreamAsync विधि, कॉन्फिगरएविट के बिना कोड के संस्करण के साथ कार्यान्वित की जाती है, उदाहरण के लिए, WPF में UI स्ट्रीम से इसे कॉल किया जाता है:

 private void button1_Click(object sender, EventArgs args) { Stream src = …, dst = …; Task t = CopyStreamToStreamAsync(src, dst); t.Wait(); // deadlock! } 

इस मामले में, प्रोग्रामर को एक अतुल्यकालिक विधि के रूप में बटन1_ क्लिक करना होगा जिसमें प्रतीक्षित ऑपरेटर से टास्क को निष्पादित करने की अपेक्षा की जाती है, और इस ऑब्जेक्ट के तुल्यकालिक प्रतीक्षा पद्धति का उपयोग नहीं किया जाता है। प्रतीक्षा विधि को कई अन्य मामलों में उपयोग करने की आवश्यकता है, लेकिन यूआई स्ट्रीम में प्रतीक्षा करने के लिए इसका उपयोग करना लगभग हमेशा एक गलती होगी, जैसा कि यहां दिखाया गया है। जब तक टास्क पूरा नहीं होगा, तब तक प्रतीक्षा पद्धति वापस नहीं आएगी। CopyStreamToStreamAsync के मामले में, इसकी एसिंक्रोनस स्ट्रीम कैप्चर किए गए सिंक्रोनाइज़ेशन कॉन्टेक्स्ट में डेटा भेजने के साथ निष्पादन को वापस करने की कोशिश करती है, और तब तक पूरा नहीं कर सकती जब तक कि इस तरह के ट्रांसफ़र पूरे नहीं हो जाते (क्योंकि वे इसके संचालन को जारी रखने के लिए आवश्यक हैं)। लेकिन ये प्रेषण, बदले में निष्पादित नहीं किया जा सकता है, क्योंकि यूआई थ्रेड जो उन्हें संभालना चाहिए, प्रतीक्षा कॉल द्वारा अवरुद्ध है। यह एक चक्रीय निर्भरता है जो गतिरोध की ओर ले जाती है। यदि CopyStreamToStreamAsync को ConfigureAwait (झूठा) के साथ लागू किया जाता है, तो कोई निर्भरता और अवरोधन नहीं होगा।

ExecutionContext ExecutionContext .NET फ्रेमवर्क का एक महत्वपूर्ण हिस्सा है, लेकिन फिर भी अधिकांश प्रोग्रामर इसके अस्तित्व से अनजान हैं। ExecutionContext – , SecurityContext LogicalCallContext, , . , ThreadPool.QueueUserWorkItem, Task.Run, Delegate.BeginInvoke, Stream.BeginRead, WebClient.DownloadStringAsync Framework, ExecutionContext ExecutionContext.Run ( ). , , ThreadPool.QueueUserWorkItem, Windows (identity), WaitCallback. , Task.Run LogicalCallContext, LogicalCallContext Action. ExecutionContext .

Framework , ExecutionContext, , . Windows LogicalCallContext . (WindowsIdentity.Impersonate CallContext.LogicalSetData) .

. C# Visual Basic , . await. , , - . C# Visual Basic («») , await (boxed) , .

. , . , , , .

C# Visual Basic , . ,

 public static async Task FooAsync() { var dto = DateTimeOffset.Now; var dt = dto.DateTime; await Task.Yield(); Console.WriteLine(dt); } 

dto await, . , , - dto:

Figure 4

 [StructLayout(LayoutKind.Sequential), CompilerGenerated] private struct <FooAsync>d__0 : <>t__IStateMachine { private int <>1__state; public AsyncTaskMethodBuilder <>t__builder; public Action <>t__MoveNextDelegate; public DateTimeOffset <dto>5__1; public DateTime <dt>5__2; private object <>t__stack; private object <>t__awaiter; public void MoveNext(); [DebuggerHidden] public void <>t__SetMoveNextDelegate(Action param0); } 

, . , , , , . , :

 public static async Task FooAsync() { var dt = DateTimeOffset.Now.DateTime; await Task.Yield(); Console.WriteLine(dt); } 

, .NET (GC) , , , : 0, , , (.NET GC 0, 1 2). , GC . , , , , , , . 0, , , . , , , .

( , ). JIT , , , , . , , . , , , , . , , . , C# Visual Basic , , .

C# Visual Basic , awaits: . await , Task , , . , , :

 public static async Task<int> SumAsync(Task<int> a, Task<int> b, Task<int> c) { return Sum(await a, await b, await c); } private static int Sum(int a, int b, int c) { return a + b + c; } 

C# “await b” Sum. await, Sum, - async , «» await. , await . , , CLR, , , . , <>t__stack. , , Tuple<int, int> <>__stack. , , , . , SumAsync :

 public static async Task<int> SumAsync(Task<int> a, Task<int> b, Task<int> c) { int ra = await a; int rb = await b; int rc = await c; return Sum(ra, rb, rc); } 

, ra, rb rc, . , : . , , , . , , , , .

, , . Sum , await , . , await , . await , Task.WhenAll:

 public static async Task<int> SumAsync(Task<int> a, Task<int> b, Task<int> c) { int [] results = await Task.WhenAll(a, b, c); return Sum(results[0], results[1], results[2]); } 

Task.WhenAll Task<TResult[]>, , , , . . , WhenAll, Task Task. , , , , , WhenAll , . WhenAll, , , params, . , , . Figure 5

Figure 5

 public static Task<int> SumAsync(Task<int> a, Task<int> b, Task<int> c) { return (a.Status == TaskStatus.RanToCompletion && b.Status == TaskStatus.RanToCompletion && c.Status == TaskStatus.RanToCompletion) ? Task.FromResult(Sum(a.Result, b.Result, c.Result)) : SumAsyncInternal(a, b, c); } private static async Task<int> SumAsyncInternal(Task<int> a, Task<int> b, Task<int> c) { await Task.WhenAll((Task)a, b, c).ConfigureAwait(false); return Sum(a.Result, b.Result, c.Result); } 

, . , . , . , , : , , / , . .NET Framework , . , .NET Framework, . , , Framework, , , .