ValueTask - क्यों, क्यों और कैसे?

अनुवाद के लिए प्रस्तावना

वैज्ञानिक लेखों के विपरीत, इस प्रकार के लेख "पाठ के करीब" का अनुवाद करना मुश्किल है, और काफी अनुकूलन किया जाना है। इस कारण से, मैं अपने लेख के लिए, मूल लेख के पाठ से निपटने के लिए, कुछ स्वतंत्रता के लिए माफी माँगता हूँ। मुझे केवल एक लक्ष्य द्वारा निर्देशित किया जाता है - अनुवाद को समझने योग्य बनाने के लिए, भले ही उन जगहों पर यह मूल लेख से दृढ़ता से विचलित हो। मैं अनुवाद के लिए रचनात्मक आलोचना और सुधार / परिवर्धन के लिए आभारी रहूंगा।

परिचय

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

कार्य

Task कई उद्देश्यों को पूरा करता है, लेकिन मुख्य "वादा" है - एक वस्तु जो एक ऑपरेशन के पूरा होने की प्रतीक्षा करने की क्षमता का प्रतिनिधित्व करती है। आप ऑपरेशन शुरू करते हैं और Task प्राप्त करते हैं। यह Task तब पूरा होगा जब ऑपरेशन स्वयं पूरा हो जाएगा। इस मामले में, तीन विकल्प हैं:

1. ऑपरेशन सर्जक थ्रेड में सिंक्रोनस को पूरा करता है। उदाहरण के लिए, जब पहले से ही बफर में कुछ डेटा तक पहुंच हो ।
2. ऑपरेशन को एसिंक्रोनस रूप से निष्पादित किया जाता है, लेकिन जब तक सर्जक Task प्राप्त करता है, तब तक पूरा कर लेता है। उदाहरण के लिए, डेटा का त्वरित उपयोग करते समय जो अभी तक बफर नहीं किया गया है
3. ऑपरेशन अतुल्यकालिक रूप से किया जाता है, और सर्जक Task प्राप्त करने के बाद समाप्त होता है Task एक उदाहरण एक नेटवर्क पर डेटा की प्राप्ति है ।

एक अतुल्यकालिक कॉल का परिणाम प्राप्त करने के लिए, ग्राहक या तो पूरा होने की प्रतीक्षा करते हुए कॉलिंग थ्रेड को ब्लॉक कर सकता है, जो अक्सर अतुल्यकालिक के विचार का खंडन करता है, या एक कॉलबैक विधि प्रदान करता है जिसे अतुल्यकालिक ऑपरेशन पूरा होने पर निष्पादित किया जाएगा। .NET 4 में कॉलबैक मॉडल को स्पष्ट रूप से प्रस्तुत किया गया था, जिसमें Task क्लास की एक वस्तु के ContinueWith विधि का उपयोग किया गया था, जिसे एक प्रतिनिधि प्राप्त हुआ था जिसे अतुल्यकालिक ऑपरेशन पूरा होने पर बुलाया गया था।

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

.NET Frmaework 4.5 और C # 5 के साथ, एसिंक्रोनस ऑपरेशन के परिणाम को प्राप्त करना async/await कीवर्ड और उनके पीछे के तंत्र को पेश करके सरल किया गया था। यह तंत्र, उत्पन्न कोड, ऊपर बताए गए सभी मामलों को अनुकूलित करने में सक्षम है, जिस पथ तक पहुंचने के बावजूद इसे सही ढंग से पूरा कर रहा है।

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

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

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

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

यह बहुत समान है कि हम कैसे तुल्यकालिक कोड लिखते हैं (उदाहरण के लिए TResult result = SomeOperation(); )। यह विकल्प स्वाभाविक रूप से async/await में अनुवादित है।

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

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

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

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

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

मान लीजिए, उसी तरह, कि ज्यादातर मामलों में, बफर में कुछ डेटा है। विधि _bufferedCount जांच _bufferedCount , यह देखती है कि चर शून्य से अधिक है, और true लौटाता true । केवल अगर सत्यापन के समय डेटा बफ़र नहीं किया गया था, तो एक अतुल्यकालिक ऑपरेशन की आवश्यकता होती है। ऐसा हो कि जैसा कि हो सकता है, केवल दो संभावित तार्किक परिणाम ( true और false ) हों, और Task<bool> माध्यम से केवल दो संभावित रिटर्न स्टेट्स हों। सिंक्रोनस पूर्णता या एसिंक्रोनस के आधार पर, लेकिन विधि से बाहर निकलने से पहले, रनटाइम Task<bool> दो उदाहरणों (एक और true लिए एक) को कैश करता है, और अतिरिक्त आवंटन से बचने के लिए वांछित रिटर्न देता है। एकमात्र विकल्प जब आपको एक नया Task<bool> बनाना होता है Task<bool> ऑब्जेक्ट एसिंक्रोनस निष्पादन का एक मामला है, जो "वापसी" के बाद समाप्त होता है। इस स्थिति में, विधि को एक नया Task<bool> ऑब्जेक्ट बनाना होगा, क्योंकि विधि से बाहर निकलने के समय, ऑपरेशन का परिणाम अभी तक ज्ञात नहीं है। लौटी हुई वस्तु अद्वितीय होनी चाहिए, क्योंकि यह अंततः अतुल्यकालिक ऑपरेशन के परिणाम को संग्रहीत करेगा।

रनटाइम से समान कैशिंग के अन्य उदाहरण हैं। लेकिन ऐसी रणनीति हर जगह लागू नहीं होती है। उदाहरण के लिए, विधि:

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

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

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

• अनुरोधित बाइट्स की संख्या लूप के अधिकांश पुनरावृत्तियों के लिए नहीं बदलती है;
• अधिकांश पुनरावृत्तियों में, ReadAsync बाइट्स की अनुरोधित संख्या पढ़ सकता है।

यही है, बार-बार कॉल के लिए, ReadAsync चलता है और पुनरावृति से पुनरावृत्ति के समान परिणाम के साथ, एक Task<int> ऑब्जेक्ट देता है। यह तर्कसंगत है कि MemoryStream अंतिम सफलतापूर्वक पूर्ण किए गए कार्य को कैश करता है, और बाद की सभी कॉल के लिए, यदि नया परिणाम पिछले एक से मेल खाता है, तो यह कैश से एक उदाहरण देता है। यदि परिणाम मेल नहीं खाता है, तो एक नया उदाहरण बनाने के लिए Task.FromResult उपयोग किया जाता है, जो बदले में, लौटने से पहले भी कैश किया जाता है।

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

ValueTask <TResult> और तुल्यकालिक पूर्णता

यह सब, अंततः .NET कोर 2.0 में एक नए प्रकार के ValueTask<TResult> को पेश करने की प्रेरणा के रूप में कार्य किया। इसके अलावा, nuget- पैकेज System.Threading.Tasks.Extensions माध्यम से, इस प्रकार को अन्य .NET रिलीज में उपलब्ध कराया गया था।

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

उपरोक्त को देखते हुए, उपरोक्त MemoryStream.ReadAsync जैसे तरीकों में कैशिंग की आवश्यकता नहीं है, लेकिन इसके बजाय निम्नानुसार लागू किया जा सकता है:

 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> और अतुल्यकालिक समाप्ति

अतुल्यकालिक तरीकों को लिखने की क्षमता रखने वाले, जो परिणाम के लिए अतिरिक्त मेमोरी आवंटन की आवश्यकता नहीं है, सिंक्रोनस पूरा होने के साथ, वास्तव में एक बड़ा प्लस है। जैसा कि ऊपर कहा गया है, यह .NET कोर 2.0 में नए ValueTask<TResult> को पेश करने का मुख्य लक्ष्य था। "हॉट सड़कों" पर उपयोग किए जाने वाले सभी नए तरीकों का उपयोग अब वापसी प्रकार के रूप में Task<TResult> बजाय ValueTask<TResult> उपयोग करते हैं। उदाहरण के लिए, .NET कोर 2.1 में (जो कि Memory<byte> बजाय Memory<byte> को पैरामीटर के रूप में लेता है) Stream लिए ReadAsync विधि का एक नया अधिभार, ValueTask<int> का एक उदाहरण देता है। इसने स्ट्रीम के साथ काम करते समय आवंटन की संख्या को काफी कम करने की अनुमति दी (बहुत बार ReadAsync विधि समकालिक रूप से समाप्त हो जाती है, जैसा कि ReadAsync साथ उदाहरण में है)।

हालांकि, उच्च बैंडविड्थ के साथ सेवाओं को विकसित करते समय, जिसमें अतुल्यकालिक समाप्ति असामान्य नहीं है, हमें अधिक आवंटन से बचने के लिए अपना सर्वश्रेष्ठ करने की आवश्यकता है।

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

इस तरह के पूल के साथ काम करने की संभावना का समर्थन करने के लिए, IValueTaskSource<TResult> इंटरफ़ेस को .NET Core 2.1 में जोड़ा गया था, और ValueTask<TResult> संरचना का विस्तार किया गया था: अब इस प्रकार की वस्तुओं को न केवल TResult या Task<TResult> वस्तुओं को लपेट सकते हैं, बल्कि यह भी IValueTaskSource<TResult> उदाहरण IValueTaskSource<TResult> । नया इंटरफ़ेस मूल कार्यक्षमता प्रदान करता है जो ValueTask<TResult> ऑब्जेक्ट्स को IValueTaskSource<TResult> के साथ उसी तरीके से काम करने की अनुमति देता है, जैसे Task<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/IsCompletedSuccessfully - आपको यह पता लगाने की अनुमति देता है कि ऑपरेशन पूरा हुआ या नहीं (सफलतापूर्वक या नहीं)। OnCompleted उपयोग ValueTask<TResult> कॉलबैक को ट्रिगर करने के लिए किया जाता है। GetResult उपयोग परिणाम प्राप्त करने के लिए, या अपवाद फेंकने के लिए किया जाता है।

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

.NET Core 2.1 में, इस तरह के एपीआई के कई उदाहरण हैं। इनमें से सबसे प्रसिद्ध Socket.ReceiveAsync का नया अधिभार है। Socket.ReceiveAsync और Socket.SendAsync तरीके। उदाहरण के लिए:

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

ValueTask<int> टाइप की ValueTask<int> रिटर्न वैल्यू के रूप में उपयोग की जाती हैं।
यदि विधि तुल्यकालिक रूप से बाहर निकलती है, तो यह मान मान के साथ ValueTask<int> लौटाता है:

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

यदि ऑपरेशन एसिंक्रोनस रूप से पूरा हो जाता है, तो एक कैश्ड ऑब्जेक्ट का उपयोग किया जाता है जो IValueTaskSource<TResult> इंटरफ़ेस को लागू करता है:

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

Socket कार्यान्वयन डेटा प्राप्त करने के लिए एक कैश्ड ऑब्जेक्ट का समर्थन करता है, और एक डेटा भेजने के लिए, जब तक उनमें से प्रत्येक का उपयोग प्रतियोगिता के बिना किया जाता है (उदाहरण के लिए, प्रतिस्पर्धी डेटा भेजना)। यह रणनीति अतुल्यकालिक निष्पादन के मामले में भी आवंटित अतिरिक्त मेमोरी की मात्रा को कम करती है।
.NET कोर 2.1 में Socket वर्णित अनुकूलन का NetworkStream के प्रदर्शन पर सकारात्मक प्रभाव पड़ा। इसका अधिभार Stream क्लास का ReadAsync विधि है:

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

बस Socket.ReceiveAsync लिए काम को Socket.ReceiveAsync विधि। मेमोरी के साथ काम करने के मामले में सॉकेट विधि की दक्षता में वृद्धि, NetworkStream विधि की दक्षता को बढ़ाती है।

गैर-जेनेरिक मान

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

लेकिन, अनावश्यक आवंटन से बचने की क्षमता और अतुल्यकालिक निष्पादन के साथ, गैर-टाइप किए गए ValueTask फिर से प्रासंगिक हो गई। इस कारण से, .NET Core 2.1 में, हमने गैर- ValueTask और IValueTaskSource । वे संबंधित सामान्य प्रकार के एनालॉग हैं, और उसी तरह से उपयोग किए जाते हैं, लेकिन खाली ( void ) रिटर्न वाले तरीकों के लिए।

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

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

• AwaitableSocketAsyncEventArgs
• AsyncOperation <TResult>
• DefaultPipeReader

इन कार्यों ( IValueTaskSource / IValueTaskSource<T> कार्यान्वयन) को सरल बनाने के लिए, हम .NET कोर 3.0 में ManualResetValueTaskSourceCore<TResult> टाइप करने की योजना बनाते हैं। यह संरचना सभी आवश्यक तर्क को ध्वस्त कर देगी। ManualResetValueTaskSourceCore<TResult> उदाहरण का उपयोग किसी अन्य ऑब्जेक्ट में किया जा सकता है जो IValueTaskSource<TResult> और / या IValueTaskSource , और इसे अधिकांश कार्य IValueTaskSource है। आप इसके बारे में ttps: //github.com/dotnet/corefx/issues/32664 पर अधिक जान सकते हैं।

ValueTasks का उपयोग करने के लिए सही मॉडल

यहां तक ​​कि एक सरसरी परीक्षा से ValueTask कि ValueTask और ValueTask<TResult> Task और Task<TResult> से अधिक सीमित ValueTask<TResult> । और यह सामान्य है, यहां तक ​​कि वांछनीय है, क्योंकि उनका मुख्य लक्ष्य अतुल्यकालिक निष्पादन के पूरा होने की प्रतीक्षा करना है।

विशेष रूप से, महत्वपूर्ण सीमाएं इस तथ्य के कारण उत्पन्न होती हैं कि ValueTask और ValueTask<TResult> पुन: प्रयोज्य वस्तुओं को एकत्र कर सकते हैं। सामान्य तौर पर, ValueTask / ValueTask<TResult> * का उपयोग करते समय निम्नलिखित कार्य * कभी नहीं किए जाने चाहिए ( मुझे "Never" * के माध्यम से सुधार करने दें):

• कभी भी एक ही ValueTask / ValueTask<TResult> ऑब्जेक्ट का बार-बार उपयोग न करें

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

• कभी भी ValueTask / ValueTask<TResult> ValueTask न ValueTask ValueTask<TResult> प्रतिस्पर्धी मोड में।

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

• ऑपरेशन पूरा होने तक .GetAwaiter().GetResult() उपयोग कभी न करें ।

प्रेरणा: IValueTaskSource / IValueTaskSource<TResult> का कार्यान्वयन ऑपरेशन पूरा होने तक लॉकिंग का समर्थन नहीं करना चाहिए। अवरुद्ध करना, वास्तव में, एक दौड़ की स्थिति की ओर जाता है, यह संभावना नहीं है कि यह उपभोक्ता की ओर से अपेक्षित व्यवहार होगा। जबकि Task / Task<TResult> आपको ऐसा करने की अनुमति देता है, जिससे ऑपरेशन पूरा होने तक कॉलिंग थ्रेड को अवरुद्ध करता है।

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

: ValueTask / ValueTask<TResult> , ( await ) (, .ConfigureAwait(false) ), .AsTask() , ValueTask / ValueTask<TResult> .

 // Given this ValueTask<int>-returning method… 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(); ... // storing the instance into a local makes it much more likely it'll be misused, // but it could still be ok // BAD: awaits multiple times ValueTask<int> vt = SomeValueTaskReturningMethodAsync(); int result = await vt; int result2 = await vt; // BAD: awaits concurrently (and, by definition then, multiple times) ValueTask<int> vt = SomeValueTaskReturningMethodAsync(); Task.Run(async () => await vt); Task.Run(async () => await vt); // BAD: uses GetAwaiter().GetResult() when it's not known to be done ValueTask<int> vt = SomeValueTaskReturningMethodAsync(); int result = vt.GetAwaiter().GetResult(); 

, "", , ( , ).

ValueTask / ValueTask<TResult> , . , IsCompleted true , ( , ), — false , IsCompletedSuccessfully true . " " , , , , , . await / .AsTask() .Result . , SocketsHttpHandler .NET Core 2.1, .ReadAsync , ValueTask<int> . , , , . , .. . क्योंकि , , , , :

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

, .. ValueTask<int> , .Result , await , .

API ValueTask / ValueTask<TResult>?

, . Task / ValueTask<TResult> .

, Task / Task<TResult> . , "" / , Task / Task<TResult> . , , ValueTask<TResult> Task<TResult> : , , await Task<TResult> ValueTask<TResult> . , (, API Task Task<bool> ), , , Task ( Task<bool> ). , ValueTask / ValueTask<TResult> . , async-, ValueTask / ValueTask<TResult> , .

, ValueTask / ValueTask<TResult> , :

1. , API ,
2. API ,
3. , , , .

, abstract / virtual , , / ?

आगे क्या है?

.NET, API, Task / Task<TResult> . , , API c ValueTask / ValueTask<TResult> , . IAsyncEnumerator<T> , .NET Core 3.0. IEnumerator<T> MoveNext , . — IAsyncEnumerator<T> MoveNextAsync . , Task<bool> , , . , , , ( ), , , await foreach -, , MoveNextAsync , ValueTask<bool> . , , , " " , . , C# , .