C #: किसी भी कार्य के लिए एक उपयोग मामला

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

पिछले संबंधित लेख

• C # एसिंक्रोनस प्रोग्रामिंग: आप प्रदर्शन के साथ कैसे कर रहे हैं?
• बराबरी और GetHashCode ओवरराइडिंग। लेकिन क्या यह जरूरी है?
• किसी और के कोड में क्या पाया जा सकता है? .NET के लिए उपयोगी सामग्रियों का चयन

C # में अतुल्यकालिक तरीकों के लगभग किसी भी गैर-मानक व्यवहार को एक उपयोगकर्ता परिदृश्य के आधार पर समझाया जा सकता है: मौजूदा सिंक्रोनस कोड को अतुल्यकालिक में परिवर्तित करना यथासंभव सरल होना चाहिए। आप वापसी टाइप करने से पहले async कीवर्ड को जोड़ने में सक्षम होना चाहिए, इस विधि के नाम के लिए Async प्रत्यय जोड़ें, और पूरी तरह कार्यात्मक एसिंक्रोनस विधि प्राप्त करने के लिए यहाँ और टेक्स्ट के क्षेत्र में प्रतीक्षा कीवर्ड जोड़ें।



एक "सरल" परिदृश्य नाटकीय रूप से अतुल्यकालिक तरीकों के व्यवहार के कई पहलुओं को बदलता है: एक कार्य की अवधि की योजना बनाने से लेकर अपवादों को संभालने तक। स्क्रिप्ट ठोस और महत्वपूर्ण लग रही है, लेकिन इसके संदर्भ में, अतुल्यकालिक तरीकों की सरलता बहुत भ्रामक हो जाती है।

सिंक संदर्भ

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

private async void buttonOk_ClickAsync(object sender, EventArgs args) { textBox.Text = "Running.."; // 1 -- UI Thread var result = await _stockPrices.GetStockPricesForAsync("MSFT"); // 2 -- Usually non-UI Thread textBox.Text = "Result is: " + result; //3 -- Should be UI Thread } 

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

प्रत्येक UI एक या अधिक विशिष्ट उपयोगकर्ता इंटरफ़ेस थ्रेड्स में मार्शलिंग कार्यों के लिए विशेष उपयोगिताओं को प्रदान करता है। Windows प्रपत्र Control.Invoke का उपयोग करता है। Control.Invoke विधि, WPF Dispatcher.Invoke विधि Control.Invoke , अन्य सिस्टम अन्य विधियों तक पहुँच सकते हैं। इन सभी मामलों में उपयोग की जाने वाली योजनाएं काफी हद तक समान हैं, लेकिन विस्तार से भिन्न हैं। सिंक्रनाइज़ेशन संदर्भ आपको "विशेष" संदर्भ में कोड चलाने के लिए एक एपीआई प्रदान करके मतभेदों से अमूर्त करने की अनुमति देता है जो कि इस तरह के व्युत्पन्न प्रकारों जैसे कि WindowsFormsSynchronizationContext , DispatcherSynchronizationContext , आदि द्वारा मामूली विवरण प्रदान करता है।

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

गतिरोध

आइए कोड का एक छोटा, अपेक्षाकृत सरल टुकड़ा देखें। क्या यहां कोई समस्या है?

 // UI code private void buttonOk_Click(object sender, EventArgs args) { textBox.Text = "Running.."; var result = _stockPrices.GetStockPricesForAsync("MSFT").Result; textBox.Text = "Result is: " + result; } // StockPrices.dll public Task<decimal> GetStockPricesForAsync(string symbol) { await Task.Yield(); return 42; } 

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

आपको आपत्ति होगी कि यह समस्या हल करने में काफी आसान है। हाँ वास्तव में। उपयोगकर्ता इंटरफ़ेस कोड से Task.Result या Task.Wait लिए सभी कॉलों को प्रतिबंधित करना आवश्यक है, हालांकि, समस्या तब भी हो सकती है यदि इस तरह के कोड का उपयोग किया गया घटक एक साथ उपयोगकर्ता ऑपरेशन के परिणाम की प्रतीक्षा कर रहा है:

 // UI code private void buttonOk_Click(object sender, EventArgs args) { textBox.Text = "Running.."; var result = _stockPrices.GetStockPricesForAsync("MSFT").Result; textBox.Text = "Result is: " + result; } // StockPrices.dll public Task<decimal> GetStockPricesForAsync(string symbol) { // We know that the initialization step is very fast, // and completes synchronously in most cases, // let's wait for the result synchronously for "performance reasons". InitializeIfNeededAsync().Wait(); return Task.FromResult((decimal)42); } // StockPrices.dll private async Task InitializeIfNeededAsync() => await Task.Delay(1); 

यह कोड फिर से गतिरोध का कारण बनता है। इसे कैसे हल करें:

• आपको Task.Wait() या Task.Result और के साथ एसिंक्रोनस कोड को ब्लॉक नहीं करना चाहिए
• लायब्रेरी कोड में ConfigureAwait(false) उपयोग करें।

पहली सिफारिश का अर्थ स्पष्ट है, और दूसरा हम नीचे बताएंगे।

प्रतीक्षित कथन कॉन्फ़िगर करना

पिछले उदाहरण में एक डेडलॉक क्यों होता है, इसके दो कारण हैं: Task.Wait() और InitializeIfNeededAsync में बाद के चरणों में सिंक्रनाइज़ेशन संदर्भ का अप्रत्यक्ष उपयोग। यद्यपि C # प्रोग्रामर कॉल को अतुल्यकालिक तरीकों से अवरुद्ध करने की अनुशंसा नहीं करते हैं, लेकिन यह स्पष्ट है कि ज्यादातर मामलों में यह अवरुद्ध अभी भी उपयोग किया जाता है। C # प्रोग्रामर एक डेडलॉक समस्या के लिए निम्नलिखित समाधान प्रदान करते हैं: Task.ConfigureAwait(continueOnCapturedContext:false) ।

अजीब उपस्थिति के बावजूद (यदि एक विधि कॉल को बिना नाम के तर्क के बिना निष्पादित किया जाता है, तो इसका मतलब कुछ भी नहीं है), यह समाधान अपना कार्य करता है: यह एक सिंक्रनाइज़ेशन संदर्भ के बिना निष्पादन की मजबूर निरंतरता प्रदान करता है।

 public Task<decimal> GetStockPricesForAsync(string symbol) { InitializeIfNeededAsync().Wait(); return Task.FromResult((decimal)42); } private async Task InitializeIfNeededAsync() => await Task.Delay(1).ConfigureAwait(false); 

इस स्थिति में, कार्य। जारी Task.Delay(1 ) कार्य (यहां खाली कथन है) थ्रेड पूल से थ्रेड में योजना बनाई गई है, और उपयोगकर्ता इंटरफ़ेस थ्रेड में नहीं, जो गतिरोध को समाप्त करता है।

सिंक्रनाइज़ेशन संदर्भ को अक्षम करना

मुझे पता है कि ConfigureAwait वास्तव में इस समस्या को हल करता है, लेकिन यह बहुत अधिक पैदा करता है। यहाँ एक छोटा सा उदाहरण है:

 public Task<decimal> GetStockPricesForAsync(string symbol) { InitializeIfNeededAsync().Wait(); return Task.FromResult((decimal)42); } private async Task InitializeIfNeededAsync() { // Initialize the cache field first await _cache.InitializeAsync().ConfigureAwait(false); // Do some work await Task.Delay(1); } 

क्या आप समस्या देखते हैं? हमने ConfigureAwait(false) इस्तेमाल किया, इसलिए सब कुछ ठीक होना चाहिए। लेकिन एक तथ्य नहीं।

ConfigureAwait(false) एक कस्टम वेटर ConfiguredTaskAwaitable हैअच्छी वस्तु, और हम जानते हैं कि इसका उपयोग केवल तभी किया जाता है जब कार्य समकालिक रूप से पूरा न हो। यही है, अगर _cache.InitializeAsync() समकालिक रूप से समाप्त होता है, तो एक गतिरोध अभी भी संभव है।

गतिरोधों को खत्म करने के लिए, ConfigureAwait(false) पद्धति के लिए कॉल के साथ पूरा होने का इंतजार करने वाले सभी कार्यों को "सजाया" जाना चाहिए। यह सब annoys और त्रुटियों को उत्पन्न करता है।

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

 private void buttonOk_Click(object sender, EventArgs args) { textBox.Text = "Running.."; var result = _stockPrices.GetStockPricesForAsync("MSFT").Result; textBox.Text = "Result is: " + result; } // StockPrices.dll public async Task<decimal> GetStockPricesForAsync(string symbol) { // The rest of the method is guarantee won't have a current sync context. await Awaiters.DetachCurrentSyncContext(); // We can wait synchronously here and we won't have a deadlock. InitializeIfNeededAsync().Wait(); return 42; } 

Awaiters.DetachCurrentSyncContext निम्न कस्टम वेटर ऑब्जेक्ट लौटाता है:

 public struct DetachSynchronizationContextAwaiter : ICriticalNotifyCompletion { /// <summary> /// Returns true if a current synchronization context is null. /// It means that the continuation is called only when a current context /// is presented. /// </summary> public bool IsCompleted => SynchronizationContext.Current == null; public void OnCompleted(Action continuation) { ThreadPool.QueueUserWorkItem(state => continuation()); } public void UnsafeOnCompleted(Action continuation) { ThreadPool.UnsafeQueueUserWorkItem(state => continuation(), null); } public void GetResult() { } public DetachSynchronizationContextAwaiter GetAwaiter() => this; } public static class Awaiters { public static DetachSynchronizationContextAwaiter DetachCurrentSyncContext() { return new DetachSynchronizationContextAwaiter(); } } 

DetachSynchronizationContextAwaiter निम्नलिखित करता है: Async विधि एक गैर-शून्य सिंक्रनाइज़ेशन संदर्भ के साथ काम करती है। लेकिन अगर IsCompleted विधि बिना सिंक्रोनाइज़ेशन के संदर्भ में काम करती है, तो IsCompleted property सही हो जाती है, और विधि की निरंतरता सिंक्रोनाइज़ की जाती है।

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

इस दृष्टिकोण के अन्य लाभ नीचे सूचीबद्ध हैं।

• त्रुटि की संभावना कम हो जाती है। ConfigureAwait(false) केवल तभी काम करता है जब सभी कार्यों को पूरा होने का इंतजार है। यह कम से कम एक चीज को भूलने के लायक है - और एक गतिरोध हो सकता है। कस्टम वेटर ऑब्जेक्ट के मामले में, याद रखें कि सभी सार्वजनिक पुस्तकालय विधियों को Awaiters.DetachCurrentSyncContext() शुरू होना चाहिए। त्रुटियां यहां संभव हैं, लेकिन उनकी संभावना बहुत कम है।
• परिणामी कोड अधिक घोषणात्मक और स्पष्ट है। कई कॉल के साथ ConfigureAwait विधि मेरे लिए कम पठनीय लगती है (अतिरिक्त तत्वों के कारण) और शुरुआती के लिए पर्याप्त जानकारीपूर्ण नहीं है।

अपवाद संभालना

इन दो विकल्पों में क्या अंतर है:

टास्क mayFail = Task.FromException (नया ArgumentNullException ());

 // Case 1 try { await mayFail; } catch (ArgumentException e) { // Handle the error } // Case 2 try { mayFail.Wait(); } catch (ArgumentException e) { // Handle the error } 

पहले मामले में, सब कुछ अपेक्षाओं को पूरा करता है - त्रुटि प्रसंस्करण किया जाता है, लेकिन दूसरे मामले में ऐसा नहीं होता है। TPL समानांतर कार्य लाइब्रेरी को अतुल्यकालिक और समानांतर प्रोग्रामिंग के लिए डिज़ाइन किया गया है, और टास्क / टास्क कई कार्यों के परिणाम का प्रतिनिधित्व कर सकता है। यही कारण है कि Task.Result और Task.Wait() हमेशा एक AggregateException फेंक देते हैं, जिसमें कई त्रुटियां हो सकती हैं।

हालांकि, हमारा मुख्य परिदृश्य सब कुछ बदल देता है: उपयोगकर्ता को त्रुटि हैंडलिंग तर्क को छूने के बिना एसिंक्स / प्रतीक्षित ऑपरेटर को जोड़ने में सक्षम होना चाहिए। अर्थात्, प्रतीक्षित कथन Task.Result से भिन्न होना चाहिए। Task.Result / Task.Wait() : यह Task.Wait() अपवाद उदाहरण में एक अपवाद के आवरण को हटा देना चाहिए। आज हम पहले अपवाद का चयन करेंगे।

सब कुछ ठीक है अगर टास्क पर आधारित सभी तरीके अतुल्यकालिक हैं और समानांतर कम्प्यूटेशन का उपयोग कार्यों को करने के लिए नहीं किया जाता है। लेकिन कुछ मामलों में, सब कुछ अलग है:

 try { Task<int> task1 = Task.FromException<int>(new ArgumentNullException()); Task<int> task2 = Task.FromException<int>(new InvalidOperationException()); // await will rethrow the first exception await Task.WhenAll(task1, task2); } catch (Exception e) { // ArgumentNullException. The second error is lost! Console.WriteLine(e.GetType()); } 

Task.WhenAll दो त्रुटियों के साथ एक कार्य देता है, हालांकि, प्रतीक्षित विवरण केवल पहले को पुनर्प्राप्त और भरता है।

इस समस्या को हल करने के दो तरीके हैं:

1. यदि उनके पास एक्सेस है, या मैन्युअल रूप से कार्य देखें
2. किसी अन्य AggregateException में लिपटे जाने के लिए अपवाद के लिए बाध्य करने के लिए TPL लाइब्रेरी कॉन्फ़िगर करें।

 try { Task<int> task1 = Task.FromException<int>(new ArgumentNullException()); Task<int> task2 = Task.FromException<int>(new InvalidOperationException()); // t.Result forces TPL to wrap the exception into AggregateException await Task.WhenAll(task1, task2).ContinueWith(t => t.Result); } catch(Exception e) { // AggregateException Console.WriteLine(e.GetType()); } 

Async शून्य विधि

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

 private async void buttonOk_ClickAsync(object sender, EventArgs args) { textBox.Text = "Running.."; var result = await _stockPrices.GetStockPricesForAsync("MSFT"); textBox.Text = "Result is: " + result; } 

लेकिन क्या होगा अगर GetStockPricesForAsync एक त्रुटि फेंकता है? एक अनहेल्दी किए गए async void विधि अपवाद को वर्तमान सिंक्रोनाइज़ेशन सन्दर्भ में मार्शल्ड किया जाता है, जो समान कोड के समान व्यवहार को ट्रिगर करता है (अधिक जानकारी के लिए AsyncMethodBuilder.cs वेब पेज का ThrowAsync विधि अनुभाग देखें)। Windows प्रपत्रों पर, ईवेंट हैंडलर में एक अनहेल्दी अपवाद Application.ThreadException इवेंट, WPF के लिए, Application.DispatcherUnhandledException इवेंट फ़ायर और इतने पर आग लगाता है।

क्या होगा अगर एसिंक्रोनस शून्य विधि को सिंक्रनाइज़ेशन संदर्भ नहीं मिलता है? इस स्थिति में, एक अनहेल्दी अपवाद एक घातक अनुप्रयोग क्रैश का कारण बनता है। यह पुनर्प्राप्त किए जाने वाले [ TaskScheduler.UnobservedTaskException ] इवेंट को फायर नहीं करेगा, लेकिन यह AppDomain.UnhandledException TaskScheduler.UnobservedTaskException इवेंट में आग लगा देगा और फिर एप्लिकेशन को बंद कर देगा। यह जानबूझकर होता है, और यह ठीक वैसा ही परिणाम है जैसा हमें चाहिए।

अब आइए एक और प्रसिद्ध तरीके से देखें: केवल उपयोगकर्ता इंटरफ़ेस इवेंट हैंडलर के लिए अतुल्यकालिक शून्य विधियों का उपयोग करना।

दुर्भाग्य से, asynch शून्य विधि दुर्घटना से कॉल करने के लिए आसान है।

 public static Task<T> ActionWithRetry<T>(Func<Task<T>> provider, Action<Exception> onError) { // Calls 'provider' N times and calls 'onError' in case of an error. } public async Task<string> AccidentalAsyncVoid(string fileName) { return await ActionWithRetry( provider: () => { return File.ReadAllTextAsync(fileName); }, // Can you spot the issue? onError: async e => { await File.WriteAllTextAsync(errorLogFile, e.ToString()); }); } 

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

निष्कर्ष

C # में अतुल्यकालिक प्रोग्रामिंग के कई पहलू एकल उपयोगकर्ता परिदृश्य से प्रभावित थे - बस मौजूदा उपयोगकर्ता इंटरफ़ेस अनुप्रयोग के सिंक्रोनस कोड को अतुल्यकालिक में परिवर्तित करना:

• परिणामी तुल्यकालन संदर्भ में अतुल्यकालिक विधियों का बाद में निष्पादन निर्धारित है, जो गतिरोध का कारण बन सकता है।
• उन्हें रोकने के लिए, एसिंक्रोनस लाइब्रेरी के कोड में हर जगह ConfigureAwait(false) कॉल करना आवश्यक है।
• कार्य का इंतजार; पहली त्रुटि पैदा करता है, और यह समानांतर प्रोग्रामिंग के लिए एक प्रसंस्करण अपवाद के निर्माण को जटिल बनाता है।
• उपयोगकर्ता इंटरफ़ेस घटनाओं को संभालने के लिए Async शून्य विधियाँ प्रस्तुत की गई हैं, लेकिन वे दुर्घटना द्वारा निष्पादित करना आसान हैं, जो कि एक अपवाद को फेंकने पर एप्लिकेशन को क्रैश कर देगा।

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