Async का उपयोग करना और C # - सर्वोत्तम प्रथाओं का इंतजार करना

C # 5.0 में शुरू किए गए async और प्रतीक्षित कीवर्ड अतुल्यकालिक प्रोग्रामिंग को बहुत सरल करते हैं। वे कुछ कठिनाइयों को भी छिपाते हैं, यदि आप सतर्कता खो देते हैं, तो आपके कोड में समस्याएं जुड़ सकती हैं। यदि आप .NET अनुप्रयोगों के लिए एसिंक्रोनस कोड बना रहे हैं, तो नीचे वर्णित अभ्यास काम आएंगे।


केवल उन स्थानों के लिए async / प्रतीक्षा का उपयोग करें जो लंबे समय तक चल सकते हैं

यहां सब कुछ सरल है। अतुल्यकालिक संचालन के प्रबंधन के लिए Task और अन्य संरचनाओं का निर्माण कुछ उपरि जोड़ता है। यदि आपका ऑपरेशन वास्तव में लंबा है, उदाहरण के लिए, आईओ अनुरोध का प्रदर्शन करना, तो ये लागत मुख्य में ध्यान देने योग्य नहीं होगी। और इस घटना में कि आपका ऑपरेशन छोटा है या कई प्रोसेसर चक्र लेता है, तो इस ऑपरेशन को सिंक्रोनाइज़ करना बेहतर हो सकता है।

सामान्य तौर पर, .NET फ्रेमवर्क पर काम करने वाली टीम ने उन सुविधाओं का चयन करने के लिए बहुत अच्छा काम किया, जो अतुल्यकालिक होनी चाहिए। इसलिए, यदि फ्रेमवर्क विधि Async में समाप्त हो जाती है और कार्य को वापस करती है, तो सबसे अधिक संभावना है कि आपको इसे अतुल्यकालिक रूप से उपयोग करना चाहिए।

टास्क पर एसिंक्स / वेट का प्राथमिकता दें

एसिंक्रोनस async/await का उपयोग करके अतुल्यकालिक कोड लिखना Task कार्यों का उपयोग करने के बजाय कोड बनाने और इसे पढ़ने की प्रक्रिया को बहुत सरल async/await है।

 public Task<Data> GetDataAsync() { return MyWebService.FetchDataAsync() .ContinueWith(t => new Data (t.Result)); } 

 public async Task<Data> GetDataAsync() { var result = await MyWebService.FetchDataAsync(); return new Data (result); } 

प्रदर्शन के संदर्भ में, ऊपर प्रस्तुत दोनों विधियों में छोटे ओवरहेड्स हैं, लेकिन वे कुछ हद तक अलग-अलग हैं क्योंकि उनमें कार्यों की संख्या बढ़ जाती है:

• Task एक निरंतरता श्रृंखला बनाता है, जो श्रृंखला में जुड़े कार्यों की संख्या के अनुसार बढ़ता है, और सिस्टम की स्थिति को कंपाइलर द्वारा पाए गए क्लोजर के माध्यम से नियंत्रित किया जाता है।
• Async/await एक नई मशीन जोड़ते समय एक अतिरिक्त मशीन का उपयोग नहीं करता है जो एक राज्य मशीन बनाता है। हालाँकि, कंपाइलर आपके कोड (और कंपाइलर) के आधार पर मशीन के स्टैक में राज्य के भंडारण के लिए अधिक चर को परिभाषित कर सकता है। MSDN पर आलेख में उत्कृष्ट विवरण है कि क्या हो रहा है।

अधिकांश परिदृश्यों में, async/await कम संसाधनों का उपयोग करेगा और Task कार्यों की तुलना में तेज़ी से चलेगा।

सशर्त कोड के लिए पहले से ही पूर्ण खाली स्थिर कार्य का उपयोग करें

कभी-कभी आप केवल किसी शर्त के तहत एक कार्य चलाना चाहते हैं। दुर्भाग्य से, NullReferenceException को NullReferenceException देगा यदि यह कार्य के बजाय null हो जाता है, और इसे संसाधित करने से आपका कोड कम पठनीय हो जाएगा।

 public async Task<Data> GetDataAsync(bool getLatestData) { Task<WebData> task = null; if (getLatestData) task = MyWebService.FetchDataAsync(); //     //      null WebData result = null; if (task != null) result = await task; return new Data (result); } 

कोड को सरल बनाने का एक तरीका एक खाली कार्य का उपयोग करना है जो पहले ही पूरा हो चुका है। परिणामी कोड क्लीनर होगा:

 public async Task<Data> GetDataAsync(bool getLatestData) { var task = getLatestData ? MyWebService.FetchDataAsync() : Empty<WebData>.Task; //     // task   null return new Data (await task); } 

सुनिश्चित करें कि कार्य स्थिर है और पूर्ण के रूप में बनाया गया है। उदाहरण के लिए:

 public static class Empty<T> { public static Task<T> Task { get { return _task; } } private static readonly Task<T> _task = System.Threading.Tasks.Task.FromResult(default(T)); } 

प्रदर्शन: अपने डेटा की तुलना में कार्यों को स्वयं कैश करना पसंद करते हैं

कार्य बनाते समय कुछ ओवरहेड है। यदि आप अपने परिणामों को कैश करते हैं, लेकिन फिर उन्हें कार्यों में बदल देते हैं, तो आप अतिरिक्त कार्य ऑब्जेक्ट बना सकते हैं।

 public Task<byte[]> GetContentsOfUrl(string url) { byte[] bytes; if (_cache.TryGetValue(url, out bytes)) //     return Task<byte[]>.Factory.StartNew(() => bytes); bytes = MyWebService.GetContentsAsync(url) .ContinueWith(t => { _cache.Add(url, t.Result); return t.Result; ); } //    (      ) private static Dictionary<string, byte[]> _cache = new Dictionary<string, byte[]>(); 

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

 public Task<byte[]> GetContentsOfUrl(string url) { Task<byte[]> bytes; if (!_cache.TryGetValue(url, out bytes)) { bytes = MyWebService.GetContentsAsync(url); _cache.Add(url, bytes); } return bytes; } //    (      ) private static Dictionary<string, Task<byte[]>> _cache = new Dictionary<string, Task<byte[]>>(); 

प्रदर्शन: समझें कि प्रतीक्षा कैसे स्थिति बनाए रखती है

जब आप async/await उपयोग करते हैं, तो कंपाइलर एक स्टेट मशीन बनाता है जो वैरिएबल और स्टैक को स्टोर करता है। उदाहरण के लिए:

 public static async Task FooAsync() { var data = await MyWebService.GetDataAsync(); var otherData = await MyWebService.GetOtherDataAsync(); Console.WriteLine("{0} = "1", data, otherdata); } 

यह कई चर के साथ एक राज्य वस्तु बनाएगा। देखें कि कंपाइलर विधि चर को कैसे बचाता है:

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

टिप्पणी 1. यदि आप एक चर की घोषणा करते हैं, तो इसे उस ऑब्जेक्ट में संग्रहीत किया जाएगा जो राज्य को संग्रहीत करता है। यह ऑब्जेक्ट को आपकी अपेक्षा से अधिक समय तक मेमोरी में बने रहने का कारण बन सकता है।

रिमार्क 2. लेकिन अगर आप वैरिएबल की घोषणा नहीं करते हैं, लेकिन await के साथ कॉल के Async मान का उपयोग करते हैं, तो वैरिएबल आंतरिक स्टैक पर जाएगा:

 public static async Task FooAsync() { var data = MyWebService.GetDataAsync(); var otherData = MyWebService.GetOtherDataAsync(); //        //      await- Console.WriteLine("{0} = "1", await data, await otherdata); } 

आपको इस बारे में बहुत चिंता नहीं करनी चाहिए जब तक आप प्रदर्शन के मुद्दे नहीं देखते हैं। यदि आप अभी भी अनुकूलन में गहराई से जाने का निर्णय लेते हैं, तो इस बारे में MSDN पर एक अच्छा लेख है: Async प्रदर्शन: Async और Await की लागत को समझना ।

स्थिरता: async / प्रतीक्षा नहीं है। कार्य नहीं

async/await Task.ContinueWith/Wait द्वारा उत्पन्न राज्य मशीन Task.ContinueWith/Wait के समान नहीं है। Task.ContinueWith/Wait सामान्य स्थिति में, आप Task से कार्यान्वयन का await कर सकते हैं, लेकिन कुछ प्रदर्शन और स्थिरता के मुद्दे हो सकते हैं। आइए अधिक विस्तार से देखें।

स्थिरता: अपने सिंक संदर्भ को जानें

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

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

कुछ तुल्यकालन संदर्भों में फिर से प्रवेश का समर्थन नहीं करते हैं और एकल-थ्रेडेड हैं। इसका मतलब यह है कि इस संदर्भ में एक समय में केवल एक ही कार्य किया जा सकता है। इसका एक उदाहरण Windows UI थ्रेड या ASP.NET संदर्भ होगा।

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

 public ActionResult ActionAsync() { // DEADLOCK:     //  ,        var data = GetDataAsync().Result; return View(data); } private async Task<string> GetDataAsync() { //     var result = await MyWebService.GetDataAsync(); return result.ToString(); } 

स्थिरता: कार्य को यहीं समाप्त करने के लिए Wait करने के लिए प्रतीक्षा का उपयोग न करें

एक सामान्य नियम के रूप में, यदि आप अतुल्यकालिक कोड बना रहे हैं, तो Wait का उपयोग करके सावधान रहें। (c await थोड़ा बेहतर है।)

एकल-थ्रेडेड सिंक्रनाइज़ेशन संदर्भों में कार्यों के लिए Wait उपयोग न करें, जैसे:

• यूआई धागे
• ASP.NET प्रसंग

अच्छी खबर यह है कि फ्रेमवर्क आपको कुछ मामलों में Task वापस करने की अनुमति देता है, और फ्रेमवर्क स्वयं कार्य पूरा होने की प्रतीक्षा करेगा। इस प्रक्रिया पर भरोसा रखें:

 public async Task<ActionResult> ActionAsync() { //    async/await   Task var data = await GetDataAsync(); return View(data); } 

यदि आप अतुल्यकालिक लाइब्रेरी बनाते हैं, तो आपके उपयोगकर्ताओं को एसिंक्रोनस कोड लिखना होगा। अतुल्यकालिक कोड लिखने के बाद से यह एक समस्या हुआ करती थी क्योंकि थकाऊ और त्रुटि-प्रवण था, लेकिन async/await के आगमन के साथ async/await अधिकांश जटिलता अब संकलक द्वारा नियंत्रित की जाती है। और आपके कोड को अधिक विश्वसनीयता मिलती है, और अब आपको ThreadPool की बारीकियों से निपटने के लिए मजबूर होने की संभावना कम है।

स्थिरता: यदि आप एक पुस्तकालय बना रहे हैं, तो ConfigureAwait का उपयोग करने पर विचार करें

यदि आपको इन संदर्भों में से किसी एक कार्य को पूरा करने के लिए प्रतीक्षा करनी है, तो आप सिस्टम को यह बताने के लिए ConfigureAwait का उपयोग कर सकते हैं कि वह आपके संदर्भ में पृष्ठभूमि कार्य नहीं करे। इसका नुकसान यह है कि पृष्ठभूमि कार्य में समान सिंक्रनाइज़ेशन संदर्भ तक पहुंच नहीं होगी, जिससे आप विंडोज यूआई या HttpContext कॉन्टेक्स्ट तक पहुंच खो देते हैं (हालांकि आपके पास अभी भी आपका सुरक्षा संदर्भ है)।

यदि आप एक "लाइब्रेरी" फ़ंक्शन बनाते हैं जो Task लौटाता है, तो आप शायद नहीं जानते कि इसे कैसे कहा जाएगा। इसलिए इसे वापस करने से पहले अपने कार्य में ConfigureAwait(false) जोड़ना सुरक्षित हो सकता है।

 private async Task<string> GetDataAsync() { // ConfigureAwait(false)  ,   //        var result = await MyWebService.GetDataAsync().ConfigureAwait(false); return result.ToString(); } 

स्थिरता: समझें कि अपवाद कैसे व्यवहार करते हैं।

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

इस मामले में नियम बहुत सीधे हैं, लेकिन कोड को देखकर सवाल का जवाब देना कभी-कभी मुश्किल होता है।

कुछ उदाहरण:

• Async / प्रतीक्षा विधि से फेंके गए अपवादों को कोड को कार्य पूरा होने के इंतजार में भेजा जाएगा (वेटर)।
  

   public async Task<Data> GetContentsOfUrl(string url) { //      ,  //    if (url == null) throw new ArgumentNullException(); var data = await MyWebService.GetContentsOfUrl(); return data.DoStuffToIt(); } 

  
  
• Task के डेलीगेट से फेंके गए एक्सेप्शन को भी कोड के लिए भेजा जाएगा ताकि Task पूरा होने का इंतजार किया जा सके (वेटर)।
  

   public Task<Data> GetContentsOfUrl(string url) { return Task<Data>.Factory.StartNew(() => { //      ,  //    if (url == null) throw new ArgumentNullException(); var data = await MyWebService.GetContentsOfUrl(); return data.DoStuffToIt(); } } 

  
  
• टास्क के निर्माण के दौरान फेंके गए अपवादों को उस कोड को भेजा जाएगा, जिसे यह विधि (कॉलर) कहा जाता है (जो सामान्य तौर पर, स्पष्ट है):
  

   public Task<Data> GetContentsOfUrl(string url) { //        if (url == null) throw new ArgumentNullException(); return Task<Data>.Factory.StartNew(() => { var data = await MyWebService.GetContentsOfUrl(); return data.DoStuffToIt(); } } 

  
  

आखिरी उदाहरण एक कारण है कि मैं Task माध्यम से Task चेन बनाने के बजाय async/await करना पसंद async/await हूं।

अतिरिक्त लिंक (अंग्रेजी में)

• MSDN: Async / Await FAQ
• " फास्ट ट्रैक " अनुकूलन की प्रतीक्षा करें
• MSDN: प्रतीक्षा करें, और UI, और गतिरोध! ओह माय!
• MSDN: Async प्रदर्शन: Async और Await की लागत को समझना