कॉन्फ़िगरविहित: अक्सर पूछे जाने वाले प्रश्न

नमस्कार, हेब्र! मैं आपके लिए स्टीफन ताउब द्वारा कन्फिगरएवाइट एफएक्यू लेख का अनुवाद प्रस्तुत करता हूं।



Async / Async को सात साल पहले .NET await जोड़ा await था। इस निर्णय का न केवल .NET पारिस्थितिकी तंत्र पर महत्वपूर्ण प्रभाव पड़ा है - यह कई अन्य भाषाओं और रूपरेखाओं में भी परिलक्षित होता है। वर्तमान में, .NET में कई सुधारों को अतुल्यकालिक का उपयोग करते हुए अतिरिक्त भाषा निर्माणों के संदर्भ में लागू किया गया है, अतुल्यकालिक समर्थन वाले एपीआई को लागू किया गया है, बुनियादी ढांचे में मूलभूत सुधार किए गए हैं जिसके कारण घड़ी की तरह async / await कार्य (विशेष रूप से, प्रदर्शन और नैदानिक ​​क्षमताओं में सुधार हुआ है) .NET कोर में)।

ConfigureAwait async / await का एक पहलू है जो प्रश्न उठाता रहता है। मुझे उम्मीद है कि मैं उनमें से कई का जवाब दे सकता हूं। मैं इस लेख को शुरू से अंत तक पठनीय बनाने की कोशिश करूंगा, और साथ ही साथ इसे अक्सर पूछे जाने वाले प्रश्नों (एफएक्यू) के उत्तर की शैली में निष्पादित करने के लिए ताकि इसे भविष्य में संदर्भित किया जा सके।

वास्तव में ConfigureAwait निपटने के लिए, हम थोड़ा पीछे जाएंगे।

एक सिंक्रोनाइज़ेशन कॉनटेक्स्ट क्या है?

System.Threading.SynchronizationContext प्रलेखन के अनुसार "विभिन्न सिंक्रोनाइज़ेशन मॉडल में सिंक्रोनाइज़ेशन संदर्भ को वितरित करने के लिए बुनियादी कार्यक्षमता प्रदान करता है।" यह परिभाषा पूरी तरह से स्पष्ट नहीं है।

99.9% मामलों में, SynchronizationContext को एक प्रकार से वर्चुअल Post विधि के साथ प्रयोग किया जाता है जो कि एसिंक्रोनस निष्पादन के लिए एक प्रतिनिधि को स्वीकार करता है ( SynchronizationContext में अन्य वर्चुअल सदस्य हैं, लेकिन वे कम सामान्य हैं और इस आलेख में चर्चा नहीं की जाएगी)। आधार प्रकार की Post विधि शाब्दिक रूप से ThreadPool.QueueUserWorkItem को कॉल करती है ताकि प्रदान प्रतिनिधि को एसिंक्रोनस रूप से निष्पादित किया जा सके। व्युत्पन्न प्रकार ओवरराइड Post ताकि प्रतिनिधि सही समय पर सही जगह पर निष्पादित कर सके।

उदाहरण के लिए, Windows प्रपत्र में एक SynchronizationContext-व्युत्पन्न प्रकार है जो Control.BeginInvoke के समतुल्य बनाने के लिए Post को फिर से परिभाषित करता है। Control.BeginInvoke । इसका अर्थ है कि इस Post विधि के लिए किसी भी कॉल के परिणामस्वरूप संबंधित नियंत्रण के साथ संबंधित थ्रेड में बाद के चरण में प्रतिनिधि को कॉल किया जाएगा - तथाकथित यूआई थ्रेड। विंडोज फॉर्म के दिल में Win32 संदेश प्रसंस्करण है। संदेश लूप को एक यूआई थ्रेड में निष्पादित किया जाता है जो बस नए संदेशों के संसाधित होने की प्रतीक्षा करता है। ये संदेश माउस मूवमेंट, क्लिक, कीबोर्ड इनपुट, सिस्टम ईवेंट, जो डेलिगेट्स द्वारा निष्पादन के लिए उपलब्ध हैं, आदि द्वारा ट्रिगर किए जाते हैं। इसलिए, यदि आपके पास Windows फॉर्म एप्लिकेशन में UI थ्रेड के लिए एक SynchronizationContext उदाहरण है, तो आपको इसमें ऑपरेशन करने के लिए Post विधि में प्रतिनिधि को पास करना होगा।

विंडोज प्रेजेंटेशन फ़ाउंडेशन (WPF) में एक ओवरराइड Post विधि के साथ एक SynchronizationContext व्युत्पन्न प्रकार भी है जो UI स्ट्रीम ( Dispatcher.BeginInvoke का उपयोग करते हुए) को "डायरेक्ट" करता है, WPF डिस्पैचर नियंत्रण के साथ, न कि विंडोज़ फॉर्म कंट्रोल।

और विंडोज रनटाइम (WinRT) का अपना SynchronizationContext व्युत्पन्न प्रकार है , जो CoreDispatcher का उपयोग करके UI थ्रेड CoreDispatcher में प्रतिनिधि को भी रखता है।

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

 internal sealed class MaxConcurrencySynchronizationContext : SynchronizationContext { private readonly SemaphoreSlim _semaphore; public MaxConcurrencySynchronizationContext(int maxConcurrencyLevel) => _semaphore = new SemaphoreSlim(maxConcurrencyLevel); public override void Post(SendOrPostCallback d, object state) => _semaphore.WaitAsync().ContinueWith(delegate { try { d(state); } finally { _semaphore.Release(); } }, default, TaskContinuationOptions.None, TaskScheduler.Default); public override void Send(SendOrPostCallback d, object state) { _semaphore.Wait(); try { d(state); } finally { _semaphore.Release(); } } } 

XUnit ढांचे में SynchronizationContext का समान कार्यान्वयन है । यहां इसका उपयोग समानांतर परीक्षणों से जुड़े कोड की मात्रा को कम करने के लिए किया जाता है।

यहां फायदे किसी भी अमूर्त के साथ समान हैं: एक एकल एपीआई प्रदान किया जाता है जिसे कार्यान्वयन विवरण को जानने की आवश्यकता के बिना, प्रोग्रामर की इच्छानुसार निष्पादन के लिए प्रतिनिधि को कतार में लगाने के लिए इस्तेमाल किया जा सकता है। मान लीजिए मैं एक पुस्तकालय लिखता हूँ जहाँ मुझे कुछ काम करने की ज़रूरत होती है और फिर एक प्रतिनिधि को मूल संदर्भ में वापस भेजना चाहिए। ऐसा करने के लिए, मुझे इसके SynchronizationContext पर कब्जा करने की आवश्यकता है, और जब मुझे पूरा करना होगा, तो मुझे इस संदर्भ की Post विधि को कॉल करना होगा और इसे निष्पादन के लिए एक प्रतिनिधि को पास करना होगा। मुझे यह जानने की जरूरत नहीं है कि विंडोज फॉर्म के लिए आपको Dispatcher से BeginInvoke उपयोग करने के लिए Control और इसके BeginInvoke उपयोग करने की आवश्यकता है, या किसी तरह एक्सयूनाइट के लिए संदर्भ और इसकी कतार प्राप्त करें। मुझे केवल वर्तमान SynchronizationContext को हथियाने और बाद में उपयोग करने की आवश्यकता है। ऐसा करने के लिए, SynchronizationContext में Current गुण होता है। इसे निम्नानुसार लागू किया जा सकता है:

 public void DoWork(Action worker, Action completion) { SynchronizationContext sc = SynchronizationContext.Current; ThreadPool.QueueUserWorkItem(_ => { try { worker(); } finally { sc.Post(_ => completion(), null); } }); } 

आप SynchronizationContext.SetSynchronizationContext विधि का उपयोग करके Current संपत्ति से एक विशेष संदर्भ सेट कर सकते हैं।

कार्य अनुसूचक क्या है?

SynchronizationContext "अनुसूचक" के लिए एक आम अमूर्त है। कुछ ढांचे इसके लिए अपने स्वयं के अमूर्त का उपयोग करते हैं, और System.Threading.Tasks कोई अपवाद नहीं है। जब Task में प्रतिनिधियों को कतारबद्ध और निष्पादित किया जा सकता है, तो वे System.Threading.Tasks.TaskScheduler के साथ जुड़े होते हैं। एक प्रतिनिधि को पंक्तिबद्ध करने के लिए एक आभासी Post विधि भी है (मानक तंत्र का उपयोग करके एक प्रतिनिधि कॉल को कार्यान्वित किया जाता है), TaskScheduler एक सार QueueTask विधि प्रदान करता है ( QueueTask विधि का उपयोग करके एक कार्य कॉल लागू किया ExecuteTask है)।

कार्य शेड्यूलर TaskScheduler.Default को लौटाने TaskScheduler.Default डिफ़ॉल्ट शेड्यूलर एक थ्रेड पूल है। TaskScheduler से Task कॉल के समय और स्थान को निर्धारित करने के तरीकों को प्राप्त करना और ओवरराइड करना भी संभव है। उदाहरण के लिए, कोर पुस्तकालयों में System.Threading.Tasks.ConcurrentExclusiveSchedulerPair टाइप होता है। इस वर्ग का एक उदाहरण दो TaskScheduler गुण प्रदान करता है: ExclusiveScheduler और TaskScheduler । ConcurrentScheduler में शेड्यूल किए गए कार्य समानांतर में किए जा सकते हैं, लेकिन जब यह बनाया जाता है ( MaxConcurrencySynchronizationContext समान) ConcurrentExclusiveSchedulerPair द्वारा निर्धारित प्रतिबंध को ध्यान में रखते हुए। यदि ExclusiveScheduler में कार्य निष्पादित किया जाता है, तो कोई ConcurrentScheduler कार्य निष्पादित नहीं किया जाएगा और केवल एक विशेष कार्य को एक समय में चलाने की अनुमति है। यह व्यवहार बहुत कुछ पढ़ने / लिखने के ताला के समान है।

SynchronizationContext TaskScheduler की तरह, TaskScheduler में एक Current प्रॉपर्टी होती है जो करंट TaskScheduler वापस TaskScheduler । हालाँकि, SynchronizationContext विपरीत, इसमें वर्तमान अनुसूचक को सेट करने के लिए विधि का अभाव होता है। इसके बजाय, शेड्यूलर वर्तमान कार्य के साथ जुड़ा हुआ है। इसलिए, उदाहरण के लिए, यह प्रोग्राम True प्रदर्शित करेगा, क्योंकि StartNew में उपयोग किए गए लैम्ब्डा को ConcurrentExclusiveSchedulerPair के ExclusiveScheduler उदाहरण में निष्पादित किया जाता है, और TaskScheduler.Current इस अनुसूचक पर स्थापित होता है:

 using System; using System.Threading.Tasks; class Program { static void Main() { var cesp = new ConcurrentExclusiveSchedulerPair(); Task.Factory.StartNew(() => { Console.WriteLine(TaskScheduler.Current == cesp.ExclusiveScheduler); }, default, TaskCreationOptions.None, cesp.ExclusiveScheduler).Wait(); } } 

दिलचस्प बात यह है कि TaskScheduler एक स्थिर FromCurrentSynchronizationContext विधि प्रदान करता है। यह विधि एक नया TaskScheduler और यह Post पद्धति का उपयोग करके लौटे SynchronizationContext.Current कॉन्टेक्स्ट.कंटर्नल संदर्भ में निष्पादन के लिए कार्यों को TaskScheduler करती है।

SynchronizationContext और TaskScheduler कैसे प्रतीक्षा से संबंधित हैं?

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

 System.InvalidOperationException: '        ,     .' 

हम Content को स्रोत संदर्भ में सेट करने के लिए SynchronizationContext TaskScheduler उपयोग मैन्युअल रूप से कर सकते हैं, उदाहरण के लिए TaskScheduler माध्यम से:

 private static readonly HttpClient s_httpClient = new HttpClient(); private void downloadBtn_Click(object sender, RoutedEventArgs e) { s_httpClient.GetStringAsync("http://example.com/currenttime").ContinueWith(downloadTask => { downloadBtn.Content = downloadTask.Result; }, TaskScheduler.FromCurrentSynchronizationContext()); } 

और हम सीधे SynchronizationContext उपयोग कर सकते हैं:

 private static readonly HttpClient s_httpClient = new HttpClient(); private void downloadBtn_Click(object sender, RoutedEventArgs e) { SynchronizationContext sc = SynchronizationContext.Current; s_httpClient.GetStringAsync("http://example.com/currenttime").ContinueWith(downloadTask => { sc.Post(delegate { downloadBtn.Content = downloadTask.Result; }, null); }); } 

हालाँकि, ये दोनों विकल्प स्पष्ट रूप से कॉलबैक का उपयोग करते हैं। इसके बजाय, हम async / await उपयोग कर सकते हैं:

 private static readonly HttpClient s_httpClient = new HttpClient(); private async void downloadBtn_Click(object sender, RoutedEventArgs e) { string text = await s_httpClient.GetStringAsync("http://example.com/currenttime"); downloadBtn.Content = text; } 

यह सब "बस काम करता है" और सफलतापूर्वक यूआई थ्रेड में Content को कॉन्फ़िगर करता है, क्योंकि मैन्युअल रूप से कार्यान्वित किए गए संस्करण के मामले में, डिफ़ॉल्ट रूप से, कार्य के लिए प्रतीक्षा करना SynchronizationContext.Current TaskScheduler.Current और TaskScheduler.Current को संदर्भित करता है। जब आप C # में कुछ "उम्मीद" करते हैं, तो संकलक मतदान के लिए कोड को परिवर्तित करता है ( GetAwaiter को कॉल GetAwaiter ) "अपेक्षित" (इस मामले में, कार्य) को "प्रतीक्षा" ( TaskAwaiter )। "प्रतीक्षा" कॉलबैक संलग्न करने के लिए ज़िम्मेदार है (जिसे अक्सर "निरंतरता" कहा जाता है) जो प्रतीक्षा पूरी होने पर राज्य मशीन को वापस कॉल करता है। वह कॉलबैक पंजीकरण के दौरान कैप्चर किए गए संदर्भ / अनुसूचक का उपयोग करके इसे लागू करता है। हम इसे थोड़ा अनुकूलित और कॉन्फ़िगर करेंगे, यह कुछ इस तरह है:

 object scheduler = SynchronizationContext.Current; if (scheduler is null && TaskScheduler.Current != TaskScheduler.Default) { scheduler = TaskScheduler.Current; } 

यहां, यह पहले चेक किया गया है कि SynchronizationContext TaskScheduler SynchronizationContext , और यदि नहीं, तो क्या कोई गैर-मानक TaskScheduler । यदि एक है, तो जब कॉलबैक कॉल के लिए तैयार है, तो कैप्चर किए गए शेड्यूलर का उपयोग किया जाएगा; यदि नहीं, तो कॉलबैक ऑपरेशन के हिस्से के रूप में निष्पादित किया जाएगा जो अपेक्षित कार्य पूरा करता है।

कॉन्फ़िगरविट क्या करता है (झूठा)

ConfigureAwait विधि विशेष नहीं है: यह किसी विशेष तरीके से संकलक या रनटाइम द्वारा मान्यता प्राप्त नहीं है। यह एक सामान्य विधि है जो एक संरचना लौटाता है ( ConfiguredTaskAwaitable - मूल कार्य को लपेटता है) और बूलियन मान लेता है। याद रखें कि await का उपयोग किसी भी प्रकार के साथ किया जा सकता है जो सही पैटर्न को लागू करता है। यदि दूसरा प्रकार लौटाया जाता है, तो इसका मतलब है कि जब संकलक को GetAwaiter विधि (पैटर्न का हिस्सा) का उपयोग प्राप्त होता है, लेकिन क्या यह ConfigureAwait प्रकार से लौटाए गए प्रकार से है, और सीधे कार्य से नहीं। यह आपको इस विशेष वेटर के लिए await व्यवहार को बदलने की अनुमति देता है।

ConfigureAwait(continueOnCapturedContext: false) द्वारा लौटाए गए प्रकार की प्रतीक्षा करने के बजाय Task लिए प्रतीक्षा करने से सीधे ऊपर चर्चा की गई संदर्भ / अनुसूचक कैप्चर कार्यान्वयन प्रभावित होता है। तर्क कुछ इस तरह बनता है:

 object scheduler = null; if (continueOnCapturedContext) { scheduler = SynchronizationContext.Current; if (scheduler is null && TaskScheduler.Current != TaskScheduler.Default) { scheduler = TaskScheduler.Current; } } 

दूसरे शब्दों में, false निर्दिष्ट करते false , भले ही कॉलबैक के लिए वर्तमान संदर्भ या शेड्यूलर हो, इसका मतलब है कि यह अनुपस्थित है।

मुझे कन्फिगरएविट (गलत) का उपयोग करने की आवश्यकता क्यों है?

ConfigureAwait(continueOnCapturedContext: false) उपयोग कॉलबैक को स्रोत संदर्भ या शेड्यूलर में कॉल करने के लिए मजबूर करने से रोकने के लिए किया जाता है। इससे हमें कई फायदे मिलते हैं:

प्रदर्शन में सुधार। कॉलिंग को पंक्तिबद्ध करने का एक ओवरहेड है, केवल कॉलिंग के विपरीत, क्योंकि इसके लिए अतिरिक्त काम (और आमतौर पर अतिरिक्त आवंटन) की आवश्यकता होती है। इसके अलावा, हम रनटाइम में अनुकूलन का उपयोग नहीं कर सकते हैं (हम अधिक अनुकूलन कर सकते हैं जब हम जानते हैं कि कॉलबैक कैसे कहा जाएगा, लेकिन अगर यह अमूर्त के मनमाने ढंग से कार्यान्वयन के लिए पारित हो जाता है, तो कभी-कभी यह प्रतिबंध लगाता है)। भारी लोड वाले वर्गों के लिए, यहां तक ​​कि वर्तमान SynchronizationContext TaskScheduler और वर्तमान TaskScheduler (दोनों जिनमें से स्थिर प्रवाह तक पहुंच होती है) की जांच करने की अतिरिक्त लागत काफी अधिक बढ़ सकती है। यदि await के बाद के कोड को मूल संदर्भ में निष्पादन की आवश्यकता नहीं होती है, तो ConfigureAwait(false) का उपयोग करके, इन सभी खर्चों से बचा जा सकता है, क्योंकि इसे अनावश्यक रूप से पंक्तिबद्ध करने की आवश्यकता नहीं है, सभी उपलब्ध अनुकूलन का उपयोग कर सकते हैं, और स्ट्रीम स्टेटिक्स तक अनावश्यक पहुंच भी बना सकते हैं।

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

क्या मुझे कॉन्फिगरएविट (सत्य) का उपयोग करने की आवश्यकता है?

नहीं, जब तक कि आपको स्पष्ट रूप से संकेत देने की आवश्यकता न हो कि आप ConfigureAwait(false) (उदाहरण के लिए, स्थैतिक विश्लेषण चेतावनी आदि को छिपाने के लिए ConfigureAwait(false) का उपयोग नहीं कर रहे हैं। ConfigureAwait(true) महत्वपूर्ण नहीं है। यदि आप await task और await task तुलना करते हैं। await task.ConfigureAwait(true) , तो वे कार्यात्मक रूप से समान होंगे। इस प्रकार, यदि ConfigureAwait(true) कोड में मौजूद है, तो इसे बिना किसी नकारात्मक परिणाम के हटाया जा सकता है।

ConfigureAwait विधि एक बूलियन मान लेती है, क्योंकि कुछ स्थितियों में कॉन्फ़िगरेशन को नियंत्रित करने के लिए एक चर को पारित करने की आवश्यकता हो सकती है। लेकिन 99% मामलों में मान गलत, ConfigureAwait(false) सेट है।

कन्फिगरवाइट (गलत) का उपयोग कब करें?

यह इस बात पर निर्भर करता है कि आप एप्लिकेशन-स्तरीय कोड या सामान्य-उद्देश्य लाइब्रेरी कोड लागू करते हैं या नहीं।

एप्लिकेशन लिखते समय, कुछ डिफ़ॉल्ट व्यवहार की आवश्यकता होती है। यदि एप्लिकेशन मॉडल / वातावरण (उदाहरण के लिए, विंडोज फॉर्म, डब्ल्यूपीएफ, एएसपी। कोर) एक विशेष SynchronizationContext प्रकाशित करता है, तो इसके लिए लगभग निश्चित रूप से एक अच्छा कारण है: इसका मतलब है कि कोड आपको एप्लिकेशन मॉडल / पर्यावरण के साथ उचित बातचीत के लिए सिंक्रोनाइज़ेशन संदर्भ का ध्यान रखने की अनुमति देता है। उदाहरण के लिए, यदि आप Windows प्रपत्र अनुप्रयोग में कोई ईवेंट हैंडलर लिखते हैं, xUnit में एक परीक्षण, या ASP.NET MVC नियंत्रक में कोड, चाहे एप्लिकेशन मॉडल ने SynchronizationContext प्रकाशित किया हो, तो यदि कोई मौजूद है तो आपको SynchronizationContext का उपयोग करना होगा। इसका मतलब यह है कि यदि ConfigureAwait(true) और await , तो कॉलबैक / निरंतरता को मूल संदर्भ में वापस भेज दिया जाता है - सब कुछ वैसा ही हो जाता है जैसा कि इसे होना चाहिए। यहां से आप एक सामान्य नियम बना सकते हैं: यदि आप एप्लिकेशन-स्तरीय कोड लिखते हैं, तो ConfigureAwait(false) उपयोग न करें । आइए क्लिक हैंडलर पर वापस जाएं:

 private static readonly HttpClient s_httpClient = new HttpClient(); private async void downloadBtn_Click(object sender, RoutedEventArgs e) { string text = await s_httpClient.GetStringAsync("http://example.com/currenttime"); downloadBtn.Content = text; } 

downloadBtn.Content = text मूल संदर्भ में downloadBtn.Content = text निष्पादित किया जाना चाहिए। यदि कोड ने इस नियम का उल्लंघन किया है और इसके बजाय ConfigureAwait (false) उपयोग किया है, तो इसका उपयोग मूल संदर्भ में नहीं किया जाएगा:

 private static readonly HttpClient s_httpClient = new HttpClient(); private async void downloadBtn_Click(object sender, RoutedEventArgs e) { string text = await s_httpClient.GetStringAsync("http://example.com/currenttime").ConfigureAwait(false); //  downloadBtn.Content = text; } 

इससे अनुचित व्यवहार होगा। वही एक क्लासिक ASP.NET अनुप्रयोग में कोड पर लागू होता है जो HttpContext.Current पर निर्भर करता है। ConfigureAwait(false) का उपयोग करते समय, Context.Current फ़ंक्शन का उपयोग करने का ConfigureAwait(false) बाद का प्रयास समस्याओं को जन्म दे सकता है।

यह वही है जो सामान्य उद्देश्य पुस्तकालयों को अलग करता है। वे भाग में सार्वभौमिक हैं क्योंकि वे उस पर्यावरण की परवाह नहीं करते हैं जिसमें उनका उपयोग किया जाता है। आप उन्हें वेब एप्लिकेशन से, क्लाइंट एप्लिकेशन से या परीक्षण से उपयोग कर सकते हैं - इससे कोई फर्क नहीं पड़ता, क्योंकि लाइब्रेरी कोड एप्लिकेशन मॉडल के लिए अज्ञेय है जिसमें इसका उपयोग किया जा सकता है। अज्ञेय का यह भी अर्थ है कि पुस्तकालय अनुप्रयोग मॉडल के साथ बातचीत करने के लिए कुछ भी नहीं करेगा, उदाहरण के लिए, यह उपयोगकर्ता इंटरफ़ेस नियंत्रण तक पहुंच प्राप्त नहीं करेगा, क्योंकि सामान्य प्रयोजन पुस्तकालय उनके बारे में कुछ भी नहीं जानता है। चूंकि किसी विशेष वातावरण में कोड को चलाने की कोई आवश्यकता नहीं है, हम मूल संदर्भ के लिए मजबूर होने के लिए निरंतरता / कॉलबैक से बच सकते हैं, और हम ConfigureAwait(false) का उपयोग करके ऐसा करते हैं, जो हमें प्रदर्शन लाभ देता है और विश्वसनीयता बढ़ाता है। यह हमें निम्नलिखित की ओर ले जाता है: यदि आप सामान्य-उद्देश्य पुस्तकालय कोड लिख रहे हैं, तो ConfigureAwait(false) उपयोग करें । यही कारण है कि .NET कोर रनटाइम लाइब्रेरीज़ में प्रत्येक (या लगभग हर) प्रतीक्षा करता है, ConfigureAwait (गलत) का उपयोग करता है; कुछ अपवादों के साथ, जो सबसे अधिक संभावना कीड़े हैं, उन्हें ठीक किया जाएगा। , PR ConfigureAwait(false) HttpClient .

. , (, , , ) , API, . , , ” " . , , Where LINQ: public static async IAsyncEnumerable<T> WhereAsync(this IAsyncEnumerable<T> source, Func<T, bool> predicate) . predicate SynchronizationContext ? WhereAsync , , ConfigureAwait(false) .

: ConfigureAwait(false) /app-model-agnostic .

ConfigureAwait (false), ?

, , . , await . , , . , , , , ConfigureAwait(false) , , .

ConfigureAwait (false) , — ?

, . FAQ. await task.ConfigureAwait(false) , ( ), ConfigureAwait(false) , - , .

, await , , SynchronizationContext TaskScheduler . , CryptoStream .NET , . awaiterयह सुनिश्चित करने के लिए कि पहले प्रतीक्षा के बाद कोड थ्रेड पूल थ्रेड में निष्पादित किया गया है। हालांकि, इस मामले में भी, आप देखेंगे कि अगला इंतजार अभी भी उपयोग कर रहा है ConfigureAwait(false); तकनीकी रूप से, यह आवश्यक नहीं है, लेकिन यह कोड समीक्षा को बहुत सरल करता है, क्योंकि यह समझने की कोई आवश्यकता नहीं है कि इसका उपयोग क्यों नहीं किया गया था ConfigureAwait(false)।

क्या ConfigureAwait (गलत) का उपयोग करने से बचने के लिए Task.Run का उपयोग करना संभव है?

हां, यदि आप लिखते हैं:

 Task.Run(async delegate { await SomethingAsync(); //     }); 

ConfigureAwait(false) SomethingAsync() , , Task.Run , , SynchronizationContext.Current null . , Task.Run TaskScheduler.Default , TaskScheduler.Current Default . , await , ConfigureAwait(false) . , . :

 Task.Run(async delegate { SynchronizationContext.SetSynchronizationContext(new SomeCoolSyncCtx()); await SomethingAsync(); //    SomeCoolSyncCtx }); 

तब कोड अंदर SomethingAsyncवास्तव में SynchronizationContext.Currentउदाहरण देखेगा SomeCoolSyncCtx। और यह await, और SomeAsync के अंदर कोई भी कॉन्फ़िगर की गई अपेक्षाएँ इस संदर्भ में वापस नहीं की जाएंगी। इस प्रकार, इस दृष्टिकोण का उपयोग करने के लिए, यह समझना आवश्यक है कि आपके द्वारा कतार में रखे गए सभी कोड क्या कर सकते हैं या क्या नहीं कर सकते हैं, और क्या इसके कार्य एक बाधा बन सकते हैं।

यह दृष्टिकोण अतिरिक्त कार्य ऑब्जेक्ट बनाने / कतार बनाने की आवश्यकता के कारण भी होता है। प्रदर्शन आवश्यकताओं के आधार पर, यह एप्लिकेशन / लाइब्रेरी के लिए महत्वपूर्ण हो सकता है या नहीं।

, , , . , , ConfigureAwait(false) CA2007 . , ConfigureAwait , , . , , - , , ConfigureAwait(false) .

SynchronizationContext.SetSynchronizationContext, ConfigureAwait (false)?

नहीं। , .

:

 Task t; SynchronizationContext old = SynchronizationContext.Current; SynchronizationContext.SetSynchronizationContext(null); try { t = CallCodeThatUsesAwaitAsync(); // await'      } finally { SynchronizationContext.SetSynchronizationContext(old); } await t; //  -     

, CallCodeThatUsesAwaitAsync null . . , await TaskScheduler.Current . TaskScheduler , await ' CallCodeThatUsesAwaitAsync TaskScheduler .

Task.Run FAQ, : , try , ( ).

:

 SynchronizationContext old = SynchronizationContext.Current; SynchronizationContext.SetSynchronizationContext(null); try { await t; } finally { SynchronizationContext.SetSynchronizationContext(old); } 

देखिए क्या समस्या है? नोटिस करना थोड़ा कठिन है, लेकिन यह प्रभावशाली है। इस बात की कोई गारंटी नहीं है कि प्रतीक्षा करने से मूल कॉल में एक कॉलबैक / जारी रहेगा। इसका मतलब यह है कि SynchronizationContextमूल में वापसी मूल धागे में नहीं हो सकती है, जो इस तथ्य को जन्म दे सकती है कि बाद में इस धागे में काम की वस्तुओं को गलत संदर्भ दिखाई देगा। इसका प्रतिकार करने के लिए, एक विशेष संदर्भ सेट करने वाले अच्छी तरह से लिखित एप्लिकेशन मॉडल आमतौर पर किसी भी अतिरिक्त कस्टम कोड को कॉल करने से पहले मैन्युअल रूप से रीसेट करने के लिए कोड जोड़ते हैं। और अगर यह एक धागे में होता है, तो भी कुछ समय लग सकता है जिसके दौरान संदर्भ ठीक से बहाल नहीं हो सकता है। और अगर यह एक अलग धागे में काम करता है, तो यह गलत संदर्भ की स्थापना को जन्म दे सकता है। और इसी तरह। आदर्श से बहुत दूर।

यदि मुझे GetAwaiter () .GetResult () का उपयोग करना है तो क्या मुझे कॉन्फिगरएविट (गलत) का उपयोग करने की आवश्यकता है?

नहीं। ConfigureAwaitकेवल कॉलबैक को प्रभावित करता है। विशेष रूप से, टेम्पलेट के लिए awaiterआवश्यक है कि आप awaiterसंपत्ति IsCompleted, विधियाँ GetResultऔर OnCompletedवैकल्पिक रूप से (असुरक्षित कैफे विधि के साथ) प्रदान करें। ConfigureAwaitकेवल व्यवहार को प्रभावित करता है {Unsafe}OnCompleted, इसलिए यदि आप सीधे कॉल करते हैं GetResult(), भले ही आप इसके माध्यम से करते हैं TaskAwaiterया ConfiguredTaskAwaitable.ConfiguredTaskAwaiterव्यवहार में कोई अंतर नहीं है। इसलिए, यदि आप देखते हैं कि task.ConfigureAwait(false).GetAwaiter().GetResult()आप इसे बदल सकते हैं task.GetAwaiter().GetResult()(इसके अलावा, सोचें कि क्या आपको वास्तव में इस तरह के कार्यान्वयन की आवश्यकता है)।

मुझे पता है कि कोड एक ऐसे वातावरण में चलता है जिसमें कभी भी एक विशेष सिंक्रोनाइज़ेशन कॉनटेक्स्ट या एक विशेष टास्कस्किडर नहीं होगा। क्या मैं कॉन्फिगरएविट (गलत) का उपयोग नहीं कर सकता हूं?

हो सकता है कि। , «». , , , , SynchronizationContext TaskScheduler , , . , , .

, .NET Core ConfigureAwait (false). ?

ऐसे नहीं।.NET कोर में काम करना उसी तरह से आवश्यक है जैसे .NET फ्रेमवर्क में काम करते समय। इस संबंध में कुछ भी नहीं बदला है।

यह बदल गया है कि क्या कुछ वातावरण अपने स्वयं के प्रकाशित करते हैं SynchronizationContext। विशेष रूप से, जबकि .NET फ्रेमवर्क में क्लासिक ASP.NET का अपना है SynchronizationContext, ASP.NET कोर नहीं है। इसका मतलब यह है कि ASP.NET कोर एप्लिकेशन में चल रहे कोड को डिफ़ॉल्ट रूप से विशेष कोड नहीं दिखाई देगा SynchronizationContext, जो ConfigureAwait(false)इस वातावरण की आवश्यकता को कम करता है।

हालांकि, इसका मतलब यह नहीं है कि कोई प्रथा SynchronizationContextया कभी नहीं होगीTaskScheduler . - ( , ) , , await ' ASP.NET Core , ConfigureAwait(false) . , , ( -) , ConfigureAwait(false) .

ConfigureAwait, « foreach» IAsyncEnumerable?

हां। . MSDN .

Await foreach , , IAsyncEnumerable<T> . , API. .NET ConfigureAwait IAsyncEnumerable<T> , , IAsyncEnumerable<T> Boolean . MoveNextAsync DisposeAsync . , , .

ConfigureAwait, 'await using' IAsyncDisposable?

, .

IAsyncEnumerable<T> , .NET ConfigureAwait IAsyncDisposable await using , , ( , DisposeAsync ):

 await using (var c = new MyAsyncDisposableClass().ConfigureAwait(false)) { ... } 

, c — MyAsyncDisposableClass , System.Runtime.CompilerServices.ConfiguredAsyncDisposable , ConfigureAwait IAsyncDisposable .

, :

 var c = new MyAsyncDisposableClass(); await using (c.ConfigureAwait(false)) { ... } 

c MyAsyncDisposableClass . c ; , .

मैंने कन्फिगरवाइट (झूठा) का इस्तेमाल किया, लेकिन मेरा एसिंक्लोक्कल इंतजार के बाद भी कोड में बहता रहा। क्या यह एक बग है?

नहीं, यह काफी अपेक्षित है। डेटा प्रवाह AsyncLocal<T>वह हिस्सा ExecutionContextहै जो इससे अलग होता है SynchronizationContext। जब तक आप स्पष्ट रूप से ExecutionContextउपयोग करने वाली धारा को अक्षम नहीं करते हैं ExecutionContext.SuppressFlow(), ExecutionContext(और इस प्रकार डेटा AsyncLocal <T>) हमेशा गुजरता रहेगा awaits, चाहे इसका उपयोग ConfigureAwaitमूल पर कब्जा करने से बचने के लिए किया जाए SynchronizationContext। इस लेख में अधिक विवरण पर चर्चा की गई है ।

क्या भाषा उपकरण मेरी लाइब्रेरी में कॉन्फिगरएविट (गलत) का स्पष्ट रूप से उपयोग करने की आवश्यकता से बचने में मेरी मदद कर सकते हैं?

लाइब्रेरी डेवलपर कभी-कभी ConfigureAwait(false)कम आक्रामक विकल्प का उपयोग करने और पूछने की आवश्यकता के बारे में शिकायत करते हैं ।

वर्तमान में वे नहीं हैं, कम से कम वे भाषा / संकलक / रनटाइम में नहीं बने हैं। हालांकि, कई सुझाव हैं कि इसे कैसे लागू किया जा सकता है, उदाहरण के लिए: 1 , 2 , 3 , 4 ।

यदि आप जिस विषय में रुचि रखते हैं, यदि आपके पास नए और दिलचस्प विचार हैं, तो मूल लेख के लेखक आपको चर्चा के लिए आमंत्रित करते हैं।