ValueTask का उपयोग क्यों, क्यों और कब करें

^{यह अनुवाद अच्छी टिप्पणी 0x1000000 के लिए धन्यवाद के बारे में आया।}

.NET फ्रेमवर्क 4 ने System.Threading.Tasks स्पेस की शुरुआत की और इसके साथ टास्क क्लास। इस प्रकार और इससे उत्पन्न टास्क <TResult> एक लंबे समय से प्रतीक्षा कर रहे हैं जब तक कि उन्हें .NET में मानकों द्वारा मान्यता प्राप्त नहीं है, अतुल्यकालिक प्रोग्रामिंग मॉडल के प्रमुख पहलुओं के रूप में जो C # 5 में अपने async / प्रतीक्षा विवरणों के साथ पेश किया गया था। इस अनुच्छेद में, मैं नए प्रकार के ValueTask / ValueTask <TResult> के बारे में बात करूंगा, उन मामलों में अतुल्यकालिक तरीकों के प्रदर्शन को बेहतर बनाने के लिए डिज़ाइन किया गया है जहां स्मृति आवंटन के ओवरहेड को ध्यान में रखा जाना चाहिए।

कार्य

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

SomeOperationAsync().ContinueWith(task => { try { TResult result = task.Result; UseResult(result); } catch (Exception e) { HandleException(e); } }); 

लेकिन .NET फ्रेमवर्क 4.5 और सी # 5 में, टास्क ऑब्जेक्ट्स को बस प्रतीक्षित ऑपरेटर द्वारा कॉल किया जा सकता है, जिससे एक एसिंक्रोनस ऑपरेशन का परिणाम प्राप्त करना आसान हो जाता है, और उपरोक्त विकल्पों के लिए अनुकूलित उत्पन्न कोड सभी मामलों में सही ढंग से काम करेगा जब ऑपरेशन सिंक्रोनस मोड में पूरा होता है, तेज एसिंक्रोनस या कॉलबैक बनाने के साथ अतुल्यकालिक:

 TResult result = await SomeOperationAsync(); UseResult(result); 

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

 TResult result = await SomeOperationAsync(); UseResult(result); 

यहां हमें कई बार निष्पादन की प्रतीक्षा करने की आवश्यकता नहीं है। हमें यह सुनिश्चित करने की आवश्यकता नहीं है कि अपेक्षाएं प्रतिस्पर्धी हैं। हमें तुल्यकालिक लॉकिंग करने की आवश्यकता नहीं है। हम कॉम्बिनेटर नहीं लिखेंगे। हम बस एक अतुल्यकालिक ऑपरेशन पूरा होने के वादे की प्रतीक्षा कर रहे हैं। अंत में, यह वह तरीका है जो हम सिंक्रोनस कोड लिखते हैं (उदाहरण के लिए, TResult परिणाम = SomeOperation ();), और इसे आम तौर पर async / प्रतीक्षा में अनुवादित किया जाता है।

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

रनटाइम और सिस्टम लाइब्रेरी कई स्थितियों में इस समस्या को कम करने में मदद करते हैं। उदाहरण के लिए, यदि हम इस तरह से एक विधि लिखते हैं:

 public async Task WriteAsync(byte value) { if (_bufferedCount == _buffer.Length) { await FlushAsync(); } _buffer[_bufferedCount++] = value; } 

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

 public async Task<bool> MoveNextAsync() { if (_bufferedCount == 0) { await FillBuffer(); } return _bufferedCount > 0; } 

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

पर्यावरण कुछ अन्य प्रकारों के लिए कैशिंग प्रदान करता है, लेकिन सभी संभावित प्रकारों को कैश करना अवास्तविक है। उदाहरण के लिए, निम्न विधि:

 public async Task<int> ReadNextByteAsync() { if (_bufferedCount == 0) { await FillBuffer(); } if (_bufferedCount == 0) { return -1; } _bufferedCount--; return _buffer[_position++]; } 

भी अक्सर तुल्यकालन निष्पादित किया जाएगा। लेकिन बुलियन के प्रकार के परिणामस्वरूप एक संस्करण के विपरीत, यह विधि Int32 देता है, जिसमें लगभग 4 बिलियन मान हैं, और टास्क <int> के सभी वेरिएंट को कैशिंग करने के लिए सैकड़ों गीगाबाइट मेमोरी की आवश्यकता होगी। पर्यावरण टास्क <int> के लिए एक छोटा कैश प्रदान करता है, लेकिन मूल्यों का एक बहुत ही सीमित सेट, उदाहरण के लिए, यदि यह विधि 4 के रिटर्न वैल्यू के साथ सिंक्रनाइज़ (डेटा पहले से ही बफर में है) समाप्त हो जाती है, तो यह कैश्ड टास्क होगा, लेकिन यदि मान 42 वापस आ जाता है, तो आपको एक नया बनाने की आवश्यकता होगी टास्क <int>, Task.FromResult (42) को कॉल करने के समान है।

कई पुस्तकालय विधियाँ अपना स्वयं का कैश प्रदान करके इसे सुचारू करने का प्रयास करती हैं। उदाहरण के लिए, MemoryStream.ReadAsync विधि के .NET फ्रेमवर्क 4.5 में एक अधिभार हमेशा तुल्यकालिक रूप से समाप्त होता है, क्योंकि यह मेमोरी से डेटा पढ़ता है। ReadAsync एक टास्क <int> लौटाता है, जहां एक Int32 परिणाम इंगित करता है कि कितने बाइट्स पढ़े गए हैं। इस विधि का उपयोग अक्सर लूप में किया जाता है, अक्सर प्रत्येक कॉल के लिए बाइट्स की समान संख्या के साथ, और अक्सर इस आवश्यकता को पूरा किया जाता है। तो ReadAsync को बार-बार कॉल करने के लिए, यह अपेक्षा करना उचित है कि टास्क <int> समान रूप से पिछले कॉल के समान मूल्य के साथ वापस आ जाएगा। इसलिए, एक मेमोरीस्ट्रीम एक वस्तु के लिए एक कैश बनाता है जो अंतिम सफल कॉल में वापस आ गया। और अगली कॉल में, यदि परिणाम दोहराया जाता है, तो यह कैश की गई वस्तु वापस कर देगा, और यदि नहीं, तो Task.FromResult के साथ एक नया बनाएं, इसे कैश में सहेजें और इसे वापस करें।

फिर भी, कई अन्य मामले हैं जब ऑपरेशन को सिंक्रोनाइज़ किया जाता है, लेकिन टास्क <TResult> ऑब्जेक्ट को बनाने के लिए मजबूर किया जाता है।

ValueTask <TResult> और तुल्यकालिक निष्पादन

इस सब के लिए .NET कोर 2.0 में एक नए प्रकार के कार्यान्वयन की आवश्यकता थी, जो कि NuGet System.Threading.Tasks.Extension के पिछले संस्करणों में उपलब्ध था: ValueTask <TResult> पैकेज।
ValueTask <TResult> को .NET Core 2.0 में बनाया गया था, जो संरचना में TResult और Task <TResult> दोनों को लपेटने में सक्षम था। इसका मतलब यह है कि इसे async विधि से लौटाया जा सकता है, और यदि इस पद्धति को सिंक्रोनाइज़ और सफलतापूर्वक निष्पादित किया जाता है, तो आपको ढेर पर किसी ऑब्जेक्ट को रखने की आवश्यकता नहीं है: आप बस इस वैल्यूस्कस्क <TResult> संरचना को वैल्यू एबॉल्ट के साथ आरंभ कर सकते हैं और इसे वापस कर सकते हैं। केवल अतुल्यकालिक निष्पादन के मामले में, टास्क <TResult> ऑब्जेक्ट रखा जाएगा, और ValueTask <TResult> इसे लपेटेगा (संरचना के आकार को कम करने और सफल निष्पादन के मामले को अनुकूलित करने के लिए, Async विधि, जो एक असमर्थित अपवाद के साथ समाप्त होती है, टास्क <TResult> को भी जगह देगी) ValueTask <TResult> बस टास्क <TResult> को भी लपेटता है, और इसके साथ अपवाद के लिए अतिरिक्त क्षेत्र नहीं ले जाएगा)।

इसके आधार पर, MemoryStream.ReadAsync जैसी एक विधि, लेकिन ValueTask <int> को वापस करते हुए, कैशिंग से निपटना नहीं चाहिए, लेकिन इसके बजाय इस तरह लिखा जा सकता है:

 public override ValueTask<int> ReadAsync(byte[] buffer, int offset, int count) { try { int bytesRead = Read(buffer, offset, count); return new ValueTask<int>(bytesRead); } catch (Exception e) { return new ValueTask<int>(Task.FromException<int>(e)); } } 

ValueTask <TResult> और अतुल्यकालिक निष्पादन

परिणाम के लिए अतिरिक्त प्लेसमेंट की आवश्यकता के बिना सिंक्रोनस को पूरा करने की क्षमता लिखने की क्षमता एक बड़ी जीत है। इसीलिए ValueTask <TResult> को .NET Core 2.0 में जोड़ा गया था, और नए तरीकों से उन अनुप्रयोगों में उपयोग किए जाने की संभावना है जिनके लिए प्रदर्शन की आवश्यकता होती है, अब टास्क <TResult> के बजाय ValueTask <TResult> की वापसी के साथ घोषित किया जाता है। उदाहरण के लिए, जब हमने .NET कोर 2.1 में स्ट्रीम क्लास का एक नया रीडायस ओवरलोड जोड़ा, तो बाइट [] के बजाय मेमोरी को पास करने में सक्षम होने के लिए, हम इसमें ValueTask <int> टाइप लौटाते हैं। इस रूप में, स्ट्रीम ऑब्जेक्ट्स (जिसमें रीडएस्पून्स विधि बहुत बार सिंक्रोनाइज़ की जाती है, जैसा कि मेमोरीस्ट्रीम के लिए पिछले उदाहरण में है) का उपयोग बहुत कम मेमोरी आवंटन के साथ किया जा सकता है।

हालाँकि, जब हम बहुत अधिक बैंडविड्थ वाली सेवाओं के साथ काम करते हैं, तब भी हम मेमोरी आवंटन से यथासंभव बचना चाहते हैं, जिसका अर्थ है कि अतुल्यकालिक निष्पादन मार्ग के साथ-साथ मेमोरी आवंटन को कम करना और समाप्त करना।
प्रतीक्षा मॉडल में, किसी भी ऑपरेशन के लिए जो अतुल्यकालिक रूप से पूरा होता है, हमें किसी ऑब्जेक्ट को वापस करने की क्षमता की आवश्यकता होती है जो ऑपरेशन के संभावित समापन का प्रतिनिधित्व करता है: कॉल करने वाले को कॉलबैक को पुनर्निर्देशित करना होगा जो ऑपरेशन के अंत में शुरू किया जाएगा, और इसके लिए हीप में एक अद्वितीय ऑब्जेक्ट की आवश्यकता होती है, जो ट्रांसमिशन चैनल के रूप में काम कर सकता है। इस विशेष ऑपरेशन। यह, एक ही समय में, इस बात का कोई मतलब नहीं है कि क्या ऑपरेशन पूरा होने के बाद इस ऑब्जेक्ट का पुन: उपयोग किया जाएगा। यदि इस ऑब्जेक्ट का पुन: उपयोग किया जा सकता है, तो एपीआई इन वस्तुओं में से एक या एक से अधिक के लिए कैश का आयोजन कर सकता है, और अनुक्रमिक संचालन के लिए इसका उपयोग कर सकता है, कई मध्यवर्ती async संचालन के लिए एक ही वस्तु का उपयोग नहीं करने के लिए, लेकिन इसका उपयोग गैर-प्रतिस्पर्धी एक्सेस के लिए करता है।
.NET Core 2.1 में, ValueTask <TResult> वर्ग को समान पूलिंग और पुन: उपयोग करने के लिए बढ़ाया गया है। केवल TResult या टास्क <TResult> को लपेटने के बजाय, एक संशोधित वर्ग एक नया IValueTaskSource <TResult> इंटरफ़ेस लपेट सकता है। यह इंटरफ़ेस मूल कार्यक्षमता प्रदान करता है जो एक अतुल्यकालिक ऑपरेशन के साथ आवश्यक है एक ValueTask <TResult> ऑब्जेक्ट के साथ उसी तरह से जैसे टास्क <TResult> करता है:

 public interface IValueTaskSource<out TResult> { ValueTaskSourceStatus GetStatus(short token); void OnCompleted(Action<object> continuation, object state, short token, ValueTaskSourceOnCompletedFlags flags); TResult GetResult(short token); } 

GetStatus पद्धति का उपयोग ValueTask <TResult> .IsCompleted जैसी संपत्तियों को लागू करने के लिए किया जाता है, जो यह जानकारी देती है कि क्या एक अतुल्यकालिक ऑपरेशन किया जाता है या पूरा किया जाता है, और यह कैसे पूरा होता है (सफल या नहीं)। OnCompleted विधि का उपयोग प्रतीक्षा ऑब्जेक्ट द्वारा ऑपरेशन पूर्ण होने पर प्रतीक्षा बिंदु से निष्पादन जारी रखने के लिए कॉलबैक संलग्न करने के लिए किया जाता है। और ऑपरेशन के परिणाम प्राप्त करने के लिए GetResult विधि की आवश्यकता होती है, इसलिए ऑपरेशन के अंत के बाद, कॉलर को TResult ऑब्जेक्ट मिल सकता है या फेंका गया कोई अपवाद पारित कर सकता है।

अधिकांश डेवलपर्स को इस इंटरफ़ेस की आवश्यकता नहीं है: विधियाँ केवल एक ValueTask लौटाती हैं <TResult> ऑब्जेक्ट, जो किसी ऑब्जेक्ट के लिए रैपर के रूप में बनाया जा सकता है जो इस इंटरफ़ेस को लागू करता है, और कॉलिंग विधि अंधेरे में रहेगी। यह इंटरफ़ेस उन डेवलपर्स के लिए है जिन्हें प्रदर्शन-महत्वपूर्ण API का उपयोग करते समय मेमोरी आवंटन से बचने की आवश्यकता होती है।

.NET Core 2.1 में ऐसे एपीआई के कई उदाहरण हैं। सबसे प्रसिद्ध विधियाँ Socket.ReceiveAsync और Socket.SendAsync हैं, जिसमें नए अधिभार 2.1 में जोड़े गए हैं, उदाहरण के लिए

 public ValueTask<int> ReceiveAsync(Memory<byte> buffer, SocketFlags socketFlags, CancellationToken cancellationToken = default); 

यह अधिभार एक ValueTask देता है <int>। यदि ऑपरेशन समकालिक रूप से पूरा हो जाता है, तो यह इसी मान के साथ एक ValueTask <int> वापस कर सकता है:

 int result = …; return new ValueTask<int>(result); 

जब एसिंक्रोनस रूप से समाप्त हो जाता है, तो यह इंटरफ़ेस को लागू करने वाले पूल से एक ऑब्जेक्ट का उपयोग कर सकता है:

 IValueTaskSource<int> vts = …; return new ValueTask<int>(vts); 

सॉकेट कार्यान्वयन स्वागत के लिए पूल में एक ऐसी वस्तु का समर्थन करता है, और एक ट्रांसमिशन के लिए, क्योंकि एक समय में निष्पादित होने की प्रतीक्षा कर रहे प्रत्येक दिशा के लिए एक से अधिक ऑब्जेक्ट नहीं हो सकता है। ये ओवरलोड स्मृति को आवंटित नहीं करते हैं, यहां तक ​​कि एक अतुल्यकालिक ऑपरेशन के मामले में भी। यह व्यवहार NetworkStream वर्ग में और स्पष्ट है।
उदाहरण के लिए, .NET Core 2.1 स्ट्रीम प्रदान करता है:

 public virtual ValueTask<int> ReadAsync(Memory<byte> buffer, CancellationToken cancellationToken); 

जिसे NetworkStream में पुनर्परिभाषित किया गया है। NetworkStream.ReadAsync विधि बस Socket.ReceiveAsync विधि का उपयोग करता है, ताकि सॉकेट में जीत NetworkStream में प्रसारित हो, और NetworkStream.ReadAsync वास्तव में या तो मेमोरी आवंटित नहीं करता है।

अनशेड वैल्यूटैस्क

जब ValueTask <TResult> .NET कोर 2.0 में दिखाई दिया, तो केवल समकालिक निष्पादन मामले को टास्क <TResult> ऑब्जेक्ट के प्लेसमेंट को बाहर करने के लिए उसमें अनुकूलित किया गया था यदि TResult मान पहले से तैयार है। इसका मतलब यह था कि गैर-जेनेरिक वैल्यूटैस्क क्लास की आवश्यकता नहीं थी: सिंक्रोनस निष्पादन के मामले के लिए, सिंगलटन टास्क ।CompletedTask को केवल विधि से वापस किया जा सकता था, और यह पर्यावरण द्वारा किए गए async में रिटर्निंग टास्क था।

हालाँकि, स्मृति को आवंटित किए बिना अतुल्यकालिक संचालन प्राप्त करने के साथ, अनसर्डेड वैल्यूटैस्क का उपयोग फिर से प्रासंगिक हो गया है। .NET Core 2.1 में, हमने जेनेरिक ValueTask और IValueTaskSource पेश किया। वे सामान्य संस्करणों के लिए समान उपयोग के लिए प्रत्यक्ष समकक्ष प्रदान करते हैं, केवल खाली रिटर्न मान के साथ।

IValueTaskSource / IValueTaskSource <T> लागू करें

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

• AwaitableSocketAsyncEventArgs
• AsyncOperation <TResult>
• DefaultPipeReader

इसे आसान बनाने के लिए, .NET कोर 3.0 में हम मैनुअल में शामिल सभी आवश्यक तर्क प्रस्तुत करने की योजना बनाते हैं। यह संरचना कार्यशीलता का थोक है। आप इसके बारे में https://github.com/dotnet/corefx/issues/32664 से डॉटनेट / कोरफैक्स रिपॉजिटरी में अधिक जान सकते हैं।

ValueTasks अनुप्रयोग पैटर्न

पहली नज़र में, ValueTask और ValueTask <TResult> का दायरा टास्क और टास्क <TResult> की तुलना में बहुत अधिक सीमित है। यह अच्छा है, और यहां तक ​​कि उम्मीद की जाती है, क्योंकि उनका उपयोग करने का मुख्य तरीका बस प्रतीक्षित ऑपरेटर का उपयोग कर रहा है।

हालाँकि, चूंकि वे पुन: उपयोग की जाने वाली वस्तुओं को लपेट सकते हैं, इसलिए टास्क और टास्क <TResult> की तुलना में उनके उपयोग पर महत्वपूर्ण प्रतिबंध हैं, यदि आप सामान्य प्रतीक्षा के सामान्य तरीके से विचलित होते हैं। सामान्य मामलों में, निम्नलिखित ऑपरेशन कभी भी ValueTask / ValueTask <TResult> के साथ नहीं किए जाने चाहिए:

• बार-बार प्रतीक्षा करें ValueTask / ValueTask <TResult> परिणाम ऑब्जेक्ट पहले से ही दूसरे ऑपरेशन में उपयोग और उपयोग किया जा सकता है। इसके विपरीत, टास्क / टास्क <TResult> एक पूर्ण अवस्था से अपूर्ण अवस्था में कभी भी संक्रमण नहीं करता है, इसलिए आप इसे आवश्यकतानुसार कई बार फिर से उम्मीद कर सकते हैं और हर बार एक ही परिणाम प्राप्त कर सकते हैं।
• समानांतर प्रतीक्षा वैल्यूटैस्क / वैल्यूस्कैस्क <TResult> परिणाम वस्तु एक समय में एक उपभोक्ता से केवल एक कॉलबैक के साथ प्रसंस्करण की उम्मीद करती है, और एक ही समय में विभिन्न प्रवाह से प्रतीक्षा करने की कोशिश कर आसानी से दौड़ और सूक्ष्म कार्यक्रम त्रुटियों को जन्म दे सकता है। इसके अलावा, यह पिछले अमान्य "पुनः प्रतीक्षा" ऑपरेशन का अधिक विशिष्ट मामला भी है। तुलना में, टास्क / टास्क <TResult> समानांतर प्रतीक्षा की किसी भी संख्या प्रदान करता है।
• का उपयोग कर .GetAwaiter ()। GetResult () जब ऑपरेशन अभी तक पूरा नहीं हुआ है। IValueTaskSource / IValueTaskSource <TResult का कार्यान्वयन ऑपरेशन पूरा होने तक लॉकिंग समर्थन की आवश्यकता नहीं है, और सबसे अधिक संभावना है कि ऐसा नहीं होगा, इसलिए इस तरह के ऑपरेशन से निश्चित रूप से रेसिंग को बढ़ावा मिलेगा और शायद कॉलिंग विधि की अपेक्षा के रूप में निष्पादित नहीं होगा। टास्क / टास्क <TResult> कार्य पूरा होने तक कॉलिंग थ्रेड को ब्लॉक करता है।

यदि आपको एक ValueTask या ValueTask <TResult> प्राप्त हुआ है, लेकिन आपको इन तीन कार्यों में से एक को निष्पादित करने की आवश्यकता है, तो आप उपयोग कर सकते हैं .AsTask (), कार्य प्राप्त करें / कार्य <TResult> और फिर प्राप्त ऑब्जेक्ट के साथ काम करें। उसके बाद, आप अब उस ValueTask / ValueTask <TResult> का उपयोग नहीं कर सकते।

संक्षेप में, नियम यह है: ValueTask / ValueTask <TResult> का उपयोग करते समय आपको या तो इसका इंतजार करना होगा (संभवत: .ConfigureAwait (झूठा) के साथ) या AsTask () को कॉल करें और अब इसका उपयोग न करें:

 //   ,  ValueTask<int> public ValueTask<int\> SomeValueTaskReturningMethodAsync(); ... // GOOD int result = await SomeValueTaskReturningMethodAsync(); // GOOD int result = await SomeValueTaskReturningMethodAsync().ConfigureAwait(false); // GOOD Task<int> t = SomeValueTaskReturningMethodAsync().AsTask(); // WARNING ValueTask<int> vt = SomeValueTaskReturningMethodAsync(); //       , //     // BAD: await   ValueTask<int> vt = SomeValueTaskReturningMethodAsync(); int result = await vt; int result2 = await vt; // BAD: await  (    ) ValueTask<int> vt = SomeValueTaskReturningMethodAsync(); Task.Run(async () => await vt); Task.Run(async () => await vt); // BAD:  GetAwaiter().GetResult(),     ValueTask<int> vt = SomeValueTaskReturningMethodAsync(); int result = vt.GetAwaiter().GetResult(); 

एक और उन्नत पैटर्न है जो प्रोग्रामर लागू कर सकते हैं, मुझे उम्मीद है, केवल सावधानीपूर्वक माप और महत्वपूर्ण लाभ प्राप्त करने के बाद। ValueTask / ValueTask <TResult> वर्गों में कई गुण होते हैं, जो ऑपरेशन की वर्तमान स्थिति की रिपोर्ट करते हैं, उदाहरण के लिए, IsCompleted संपत्ति सही है अगर ऑपरेशन पूरा हुआ (अर्थात, यह अब नहीं चलता है और सफलतापूर्वक पूरा हुआ या सफलतापूर्वक पूरा नहीं हुआ है), और IsCompletedSuccessfully संपत्ति का सही रिटर्न देता है अगर यह सफलतापूर्वक पूरा हुआ (परिणाम की प्रतीक्षा और प्राप्त करते समय, यह अपवाद नहीं था)। निष्पादन की सबसे अधिक मांग वाले थ्रेड्स के लिए, जहाँ डेवलपर एसिंक्रोनस मोड में उत्पन्न होने वाली लागतों से बचना चाहता है, इन गुणों को एक ऑपरेशन से पहले जांचा जा सकता है जो वास्तव में ValueTask / ValueTask <TResult> ऑब्जेक्ट को नष्ट कर देते हैं, उदाहरण के लिए प्रतीक्षा करें, .AsTask ()। उदाहरण के लिए, .NET Core 2.1 में SocketsHttpHandler के कार्यान्वयन में, कोड कनेक्शन से पढ़ता है और एक ValueTask <int> प्राप्त करता है। यदि यह ऑपरेशन सिंक्रोनाइज़ किया जाता है, तो हमें ऑपरेशन के जल्दी समाप्त होने की चिंता नहीं करनी चाहिए। लेकिन अगर यह एसिंक्रोनस रूप से चलता है, तो हमें बाधित प्रसंस्करण को हुक करना चाहिए ताकि बीच में अनुरोध कनेक्शन को तोड़ दे। चूंकि यह कोड का एक बहुत ही तनावपूर्ण टुकड़ा है, अगर प्रोफाइलिंग में निम्नलिखित छोटे बदलाव की आवश्यकता दिखाई देती है, तो इसे इस तरह संरचित किया जा सकता है:

 int bytesRead; { ValueTask<int> readTask = _connection.ReadAsync(buffer); if (readTask.IsCompletedSuccessfully) { bytesRead = readTask.Result; } else { using (_connection.RegisterCancellation()) { bytesRead = await readTask; } } } 

क्या हर नई एसिंक्रोनस एपीआई विधि एक ValueTask / ValueTask <TResult> लौटाएगी?

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

- ValueTask/ValueTask<TResult> : ) , await, ) , ) , . , / .

ValueTask ValueTask<TResult>?

.NET , Task/Task<TResult>, , ValueTask/ValueTask<TResult>, , . – IAsyncEnumerator<T>, .NET Core 3.0. IEnumerator<T> MoveNext, bool, IAsyncEnumerator<T> MoveNextAsync. , , Task, . , , , ( ), await foreach, ValueTask. , . C# , , , .