🕚 ♀️ 🌭 System.IO। पाइपलाइन - उच्च प्रदर्शन के प्रेमियों के लिए एक अल्पज्ञात उपकरण 🖤 🐭 🤬

नमस्कार पाठक। .NET Core 2.1 को रिलीज़ हुए काफी समय बीत चुका है। और स्पैन और मेमोरी जैसे शांत नवाचार पहले से ही व्यापक रूप से ज्ञात हैं, आप उनके बारे में बहुत कुछ पढ़, देख और सुन सकते हैं। हालाँकि, दुर्भाग्य से, लाइब्रेरी को System.IO कहा जाता है। पाइपलाइन्स को समान ध्यान नहीं मिला। इस विषय पर लगभग सब कुछ एकमात्र पोस्ट है जिसे कई संसाधनों पर अनुवादित और कॉपी किया गया है। उस तकनीक के बारे में अधिक जानकारी होनी चाहिए ताकि उसे विभिन्न कोणों से देखा जा सके।

परिचय

इसलिए, इस लाइब्रेरी का उद्देश्य स्ट्रीमिंग डेटा के प्रसंस्करण को गति देना है। यह मूल रूप से Kestrel (ASP.NET Core के लिए एक क्रॉस-प्लेटफॉर्म वेब सर्वर) की विकास टीम द्वारा बनाया और उपयोग किया गया था, लेकिन वर्तमान में यह नगेट पैकेज के माध्यम से नश्वर लोगों के लिए उपलब्ध है।

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

System.IO.Pipelines सभी धाराओं को प्रतिस्थापित करने का लक्ष्य नहीं रखता है, यह उच्च प्रदर्शन कोड लिखने वाले डेवलपर के शस्त्रागार में एक अतिरिक्त उपकरण है। मेरा सुझाव है कि आप खुद को बुनियादी तरीकों और कक्षाओं से परिचित करें, उनके कार्यान्वयन विवरण देखें और बुनियादी उदाहरणों का विश्लेषण करें।

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

लाइब्रेरी के इंटर्नल्स भाषा और रनटाइम के नवीनतम संस्करणों की व्यापक संभावनाओं का उपयोग करते हैं - स्पैन, मेमोरी, ऑब्जेक्ट पूल, वैल्यूस्कैस्क और इतने पर। उत्पादन में इन सुविधाओं का उपयोग करने के एक महान उदाहरण के लिए यह कम से कम देखने लायक है।

एक समय में, कुछ डेवलपर्स C # में धाराओं के कार्यान्वयन से संतुष्ट नहीं थे, क्योंकि एक वर्ग का उपयोग पढ़ने और लिखने दोनों के लिए किया जाता था। लेकिन जैसा कि वे कहते हैं, आप तरीकों को एक वर्ग से बाहर नहीं फेंक सकते। यहां तक कि अगर स्ट्रीम पढ़ने / लिखने / चाहने का समर्थन नहीं करता है, तो CanRead, CanWrite और CanSeek संपत्तियों का उपयोग किया जाता है। यह एक छोटी बैसाखी की तरह दिखता है। लेकिन अब हालात अलग हो गए।

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

आइए पाइप क्लास के साथ शुरुआत करें

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

इस वर्ग का उपयोग शुरू करने के लिए आपको पाइप वर्ग का एक उदाहरण बनाना चाहिए और उल्लिखित गुणों का उपयोग करके पाइपरीडर और पाइपविटर ऑब्जेक्ट प्राप्त करना चाहिए।

सरल आरंभीकरण

var pipe = new Pipe(); PipeWriter pipeWriter = pipe.Writer; PipeReader pipeReader = pipe.Reader;

पाइप के साथ काम करने के तरीकों पर विचार करें:
पाइपवर्टर के साथ लेखन - राइटएस्प्यूंस, गेटमेरी / गेटस्पैन, एडवांस, फ्लशएस्क्यू, कम्प्लीट, कैंसलिंगफ्लश, ऑनरेडरप्लेक्टेड।

पाइपराइडर के साथ पढ़ना - एडवांसटैटो, रीडासिंक, ट्राइ रीड, कम्प्लीट, कैंपेनिंग, रीडिंग, ऑनराइटरकंप्लीट।

जैसा कि उल्लेख पोस्ट में कहा गया है, वर्ग बफ़र्स की एक एकल लिंक की गई सूची का उपयोग करता है। लेकिन, जाहिर है, वे पाइपराइडर और पाइपविटर के बीच स्थानांतरित नहीं होते हैं - सभी तर्क एक वर्ग में हैं। इस सूची का उपयोग पढ़ने और लिखने दोनों के लिए किया जाता है। इसके अलावा, लौटा डेटा इस सूची में संग्रहीत किया जाता है (इसलिए कोई प्रतिलिपि नहीं बनाई गई)।

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

पाइपविटर विधियों से शुरुआत करना

# 1 ValueTask <FlushResult> WriteAsync (ReadOnlyMemory <बाइट> स्रोत, रद्दीकरण टिप्पणी रद्द करेंटोकन)

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

फिर सवाल उठ सकता है कि कैसे कुछ लिखें, अगर सबसे स्पष्ट और केवल उपयुक्त विधि के माध्यम से नहीं

# 2 मेमोरी <बाइट> GetMemory (int sizeHint)

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

मैं ऐसे उदाहरण को देखने का सुझाव देता हूं। पहली नज़र में, ऐसा लग सकता है कि संकलक (या रनटाइम) ने दानव को आघात पहुँचाया है।

द्वेष

  var pipeNoOptions = new Pipe(); Memory<byte> memoryOne = pipeNoOptions.Writer.GetMemory(2); Console.WriteLine(memoryOne.Length); //2048 or 4096 var pipeWithOptions = new Pipe(new PipeOptions(minimumSegmentSize: 5)); Memory<byte> memoryTwo = pipeWithOptions.Writer.GetMemory(2); Console.WriteLine(memoryTwo.Length); //16

लेकिन इस उदाहरण में सब कुछ समझ में आता है और सरल है।
पाइप इंस्टेंस बनाते समय, हम इसे बनाने के लिए विकल्पों के साथ कन्स्ट्रक्टर में पाइपऑक्शन ऑब्जेक्ट को पास कर सकते हैं।

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

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

# 2.5 स्पैन <बाइट> गेटस्पैन (int sizeHint)

यह इसी तरह से काम करता है, स्पैन को मेमोरी से देता है।

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

# 3 शून्य अग्रिम (इंट बाइट्स)

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

ऐसा लगता है कि इसके बाद पाठक डेटा प्राप्त कर सकता है। लेकिन एक और कदम की जरूरत है।

# 4 वैल्यूटैस्क <FlushResult> FlushAsync (कैंसिलेशनटोकन कैंसलेशनटोकन)

प्राप्त मेमोरी (गेटमेमोरी) को आवश्यक डेटा लिखने के बाद विधि को कहा जाता है और यह दर्शाता है कि हमने वहां कितना लिखा (एडवांस)। यह मान ValueTask देता है, हालांकि यह अतुल्यकालिक (इसके वंशज स्ट्रीमपाइटर के विपरीत) नहीं है। ValueTask एक विशेष प्रकार (रीडऑनली स्ट्रक्चर) है जिसका उपयोग उस स्थिति में किया जाता है जब अधिकांश कॉल एसिंक्रोनस नहीं होंगी, अर्थात इसके कॉल के समय सभी आवश्यक डेटा उपलब्ध होंगे और विधि सिंक्रोनाइज़ हो जाएगी। अपने आप में यह या तो डेटा या कार्य समाहित करता है (यदि यह समकालिक रूप से काम नहीं करता है)। यह _writerAwaitable.IsCompleted property पर निर्भर करता है। यदि हम इस _writerAwaitable की स्थिति में क्या परिवर्तन देखते हैं, तो हम देखेंगे कि ऐसा तब होता है जब उपभोग किए गए डेटा की मात्रा नहीं होती है (यह बिल्कुल वैसा नहीं है जैसा कि बाद में जांचे गए डेटा को नहीं समझाया जाएगा) एक निश्चित सीमा से अधिक है (_wauseWriterThreshold)। डिफ़ॉल्ट मान 16 खंड आकार है। यदि वांछित है, तो मान को पाइप ऑक्शन में बदला जा सकता है। इसके अलावा, यह विधि ReadAsync विधि की निरंतरता शुरू करती है, अगर कोई अवरुद्ध था।

एक FlushResult देता है जिसमें 2 गुण होते हैं - IsCanceled और IsCompleted। IsCanceled इंगित करता है कि क्या फ़्लश को रद्द कर दिया गया है (रद्द करें लंबित () कॉल)। IsCompleted इंगित करता है कि क्या pipReader पूरा हो चुका है (पूर्ण कॉल करके) या कम्पलीटासिंक्स () विधियों)।
विधि का मुख्य भाग लॉक के तहत किया जाता है।

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

# 5 शून्य पूर्ण (अपवाद अपवाद = अशक्त) या वैल्यूटैस्क कम्प्लीटैन्सिंक (अपवाद अपवाद = अशक्त)

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

# 6 शून्य रद्द करें लंबित ()

जैसा कि नाम से ही स्पष्ट है, यह वर्तमान फ्लुशसंक () ऑपरेशन को रद्द करता है। एक ताला है।

# 7 शून्य OnReaderCompleted (क्रिया <अपवाद, ऑब्जेक्ट> कॉलबैक, ऑब्जेक्ट स्थिति)

पाठक के पूरा होने पर पारित प्रतिनिधि को निष्पादित करें। ताला भी है।
प्रलेखन में वर्तमान में लिखा गया है कि इस पद्धति को कुछ पाइपवर्टर कार्यान्वयन पर नहीं बुलाया जा सकता है और भविष्य में हटा दिया जाएगा। इसलिए, आपको इन तरीकों से तर्क नहीं बाँधना चाहिए।

यह पाइपरीडर का समय है

# 1 ValueTask <ReadResult> ReadAsync (रद्दीकरण टोकन टोकन)

यहां, फ्लशएस्क्यूएन () की तरह, वैल्यूसैस्क लौटाया गया है, जो संकेत देता है कि विधि ज्यादातर तुल्यकालिक है, लेकिन हमेशा नहीं। _ReaderAwaitable की स्थिति पर निर्भर करता है। FlushAsync के साथ, आपको यह खोजने की आवश्यकता है कि _readerAwaitable अधूरा पर सेट है। यह तब होता है जब पाइपरीडर ने आंतरिक सूची से सब कुछ पढ़ा है (या इसमें वह डेटा है जिसे जांच के रूप में चिह्नित किया गया था और आपको जारी रखने के लिए अधिक डेटा की आवश्यकता है)। जो, वास्तव में, स्पष्ट है। तदनुसार, हम यह निष्कर्ष निकाल सकते हैं कि अनुभवजन्य रूप से पहचाने गए आँकड़ों के आधार पर, अपने काम को ठीक से ट्यून करना वांछनीय है, इसके सभी विकल्पों को सोच-समझकर सेट करना। उचित कॉन्फ़िगरेशन एक अतुल्यकालिक निष्पादन शाखा की संभावना को कम करेगा और डेटा के अधिक कुशल प्रसंस्करण की अनुमति देगा। पूरी विधि में लगभग सभी कोड एक लॉक से घिरा हुआ है।

रिटर्न कुछ रहस्यमय ReadResult । वास्तव में, यह ऑपरेशन की स्थिति दिखाते हुए सिर्फ एक बफर + झंडे है (Iscanceled - क्या ReadAsync को रद्द कर दिया गया था और क्या यह इंगित करता है कि क्या पाइपवर्टर बंद था)। IsCompleted एक ऐसा मान है जो यह बताता है कि क्या पाइपवर्टर कम्प्लीट () या कम्पैरेसिंक्स () विधियों को कहा गया था। यदि इन विधियों को पारित किए गए अपवाद के साथ बुलाया गया था, तो इसे पढ़ने की कोशिश करने पर फेंक दिया जाएगा।

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

चर्चा का विषय - ReadOnlySequence वर्ग में, अशक्त संदर्भ प्रकार सक्रिय रूप से उपयोग किए जाते हैं और इसमें गोटो (गहरे लूप नेस्टिंग के लिए नहीं और उत्पन्न कोड में नहीं) - विशेष रूप से, यहां ।

प्रसंस्करण के बाद, आपको उस पाइप उदाहरण को इंगित करने की आवश्यकता है जिसे हम डेटा पढ़ते हैं।

# 2 बूल TryRead (बाहर पढ़ेंResult परिणाम)

तुल्यकालिक संस्करण। यदि यह मौजूद है तो आपको परिणाम प्राप्त करने की अनुमति देता है। अन्यथा, ReadAsync के विपरीत यह ब्लॉक नहीं होता है और गलत रिटर्न देता है। साथ ही इस विधि का कोड लॉक में है।

# 3 शून्य एडवांसटॉ (अनुक्रम अनुक्रम का सेवन, अनुक्रम जांच की गई)

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

# 4 शून्य पूर्ण (अपवाद अपवाद = अशक्त)

पाइपरीडर को पूरा करता है। यदि इस बिंदु पर पाइपविटर पूरा हो जाता है, तो पूरा पाइप उदाहरण पूरा हो जाता है। अंदर से ताला।

# 5 शून्य रद्द करें लंबित ()

आपको वर्तमान में लंबित पठन को रद्द करने की अनुमति देता है। ताला।

# 6 शून्य OnWriterCompleted (क्रिया <अपवाद, ऑब्जेक्ट> कॉलबैक, ऑब्जेक्ट स्थिति)

आपको पाइपवर्टर के पूरा होने पर प्रतिनिधि को निर्दिष्ट करने की अनुमति देता है।
पाइपवर्टर के समान तरीके की तरह, प्रलेखन में भी वही टैग है जिसे हटा दिया जाएगा। ताला हुड के नीचे है।

उदाहरण

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

एक शक्तिशाली विशेषता के लिए विकास के वर्ष - अतुल्यकालिक मुख्य

  class Program { static async Task Main(string args) { var pipe = new Pipe(); var dataWriter = new PipeDataWriter(pipe.Writer, "testpipe"); var dataProcessor = new DataProcessor(new ConsoleBytesProcessor(), pipe.Reader); var cts = new CancellationTokenSource(); await Task.WhenAll(dataWriter.ReadFromPipeAsync(cts.Token), dataProcessor.StartProcessingDataAsync(cts.Token)); } }

PipeDataWriter

  public class PipeDataWriter { private readonly NamedPipeClientStream _namedPipe; private readonly PipeWriter _pipeWriter; private const string Servername = "."; public PipeDataWriter(PipeWriter pipeWriter, string pipeName) { _pipeWriter = pipeWriter ?? throw new ArgumentNullException(nameof(pipeWriter)); _namedPipe = new NamedPipeClientStream(Servername, pipeName, PipeDirection.In); } public async Task ReadFromPipeAsync(CancellationToken token) { await _namedPipe.ConnectAsync(token); while (true) { token.ThrowIfCancellationRequested(); //// when working with the asynchronous method, use Memory <T> //Memory<byte> buffer = _pipeWriter.GetMemory(); //// asynchronous reading from a named pipe in Memory <T> //// there can be any operation to obtain data - from reading from a file to random generation. //int readBytes = await _namedPipe.ReadAsync(buffer, token); // synchronous reading from the named pipe to the requested from PipeWriter Span // there can be any operation to obtain data - from reading from a file to random generation. int readBytes = _namedPipe.Read(_pipeWriter.GetSpan()); // if there was nothing in the channel, release the thread for half a second and try again // in other cases we can break the loop, it's just example if (readBytes == 0) { await Task.Delay(500, token); continue; } // specify the amount of bytes read from the pipe _pipeWriter.Advance(readBytes); // flush data to make them available PipeReader FlushResult result = await _pipeWriter.FlushAsync(token); // if PipeReader has been completed, it no longer needs to write data // PS this behavior was chosen by me as an example, it depends on business logic if (result.IsCompleted) { break; } } // complete _pipeWriter to complete the entire instance of pipe _pipeWriter.Complete(); } }

DataProcessor

  public class DataProcessor { private readonly IBytesProcessor _bytesProcessor; private readonly PipeReader _pipeReader; public DataProcessor(IBytesProcessor bytesProcessor, PipeReader pipeReader) { _bytesProcessor = bytesProcessor ?? throw new ArgumentNullException(nameof(bytesProcessor)); _pipeReader = pipeReader ?? throw new ArgumentNullException(nameof(pipeReader)); } public async Task StartProcessingDataAsync(CancellationToken token) { while (true) { token.ThrowIfCancellationRequested(); // reading data from a pipe instance ReadResult result = await _pipeReader.ReadAsync(token); ReadOnlySequence<byte> buffer = result.Buffer; // We perform calculations with the data obtained. await _bytesProcessor.ProcessBytesAsync(buffer, token); // indicate to which position the data was processed. In this case, everything is written to the file. // in situations where not all data has been processed, you need to create a position manually using the buffer and index // in this situation, IBytesProcessor.ProcessBytesAsync can be supplemented by returning this position _pipeReader.AdvanceTo(buffer.End); // if PipeWriter has been completed, reading is no longer necessary // this behavior was chosen by me as an example, it depends on business logic if (result.IsCompleted) { break; } } // complete _pipeReader to complete the entire instance of pipe _pipeReader.Complete(); } }

BytesProcessor

  public interface IBytesProcessor { Task ProcessBytesAsync(ReadOnlySequence<byte> bytesSequence, CancellationToken token); } public class ConsoleBytesProcessor : IBytesProcessor { //Let's imagine that in this class there is a normal constructor and IDisposable readonly FileStream _fileStream = new FileStream("buffer", FileMode.Create); public Task ProcessBytesAsync(ReadOnlySequence<byte> bytesSequence, CancellationToken token) { if (bytesSequence.IsSingleSegment) { ProcessSingle(bytesSequence.First.Span); } else { foreach (var segment in bytesSequence) { ProcessSingle(segment.Span); } } return Task.CompletedTask; } private void ProcessSingle(ReadOnlySpan<byte> span) { _fileStream.Write(span); } }

System.IO। पाइपलाइन - उच्च प्रदर्शन के प्रेमियों के लिए एक अल्पज्ञात उपकरण