क्या हमें अभी भी रिचटर के AsyncEnumerator की आवश्यकता है?

Question

हाल ही में मैंने AsyncEnumerator क्लास फॉर्म जेफरी रिचटर की पावर थ्रेडिंग लाइब्रेरी में ठोकर खाई, जो आमतौर पर प्रोग्रामिंग एसिंक्रोनस सामान के दौरान कई समस्याओं का समाधान कर रहा है।

इस कक्षा का विचार काफी समय से आसपास रहा है और मैं सोच रहा हूं कि .NET/C# के वर्तमान संस्करणों ने अब इस तंत्र के लिए अंतर्निहित समर्थन किया है या यदि अभी भी एक पर भरोसा करना आवश्यक है तीसरी पार्टी पुस्तकालय? या हो सकता है कि .NET के नए संस्करणों में कुछ वैकल्पिक दृष्टिकोण हैं जो अतुल्यकालिक प्रोग्रामिंग को उतना ही सरल बनाता है जितना रिचटर एसिंक एन्यूमेरेटर करता है?

या दूसरे शब्दों में: क्या आज रिचटर के असिनक्यूमेरेटर का उपयोग शुरू करने का कोई कारण नहीं है?

संपादित करें: AsyncEnumerator के बारे में जानकारी के साथ

कुछ लिंक:

• Jeffrey Richter and his AsyncEnumerator
• Simplified APM With The AsyncEnumerator
• More AsyncEnumerator Features

Answer 1

हां, आपको अभी भी मेरे AsyncEnumerator से लाभ होगा। .NET 4 (कार्य, समांतर, PLINQ, आदि) में पेश की गई नई थ्रेडिंग सामग्री, समरूपता के बारे में है। यही है, वे सभी एक कम्प्यूटेशनल वर्कलोड लेने, इसे विभाजित करने और इसे कई धागे पर फैलाने के बारे में हैं ताकि वर्कलोड कम समय में पूरा हो सके, यह पूरे वर्कलोड को करने के लिए 1 थ्रेड लेगा। आप इन संरचनाओं का एक साथ कई सिंक्रोनस I/O संचालन निष्पादित करने के लिए उपयोग कर सकते हैं। हालांकि, सिंक्रोनस I/O ऑपरेशंस सभी धागे को अवरुद्ध करने का कारण बनता है जो थ्रेडपूल को अधिक धागे बनाने का कारण बनता है। और इसलिए, आपके ऐप का संसाधन उपयोग skyrockets जबकि आपका CPU उपयोग बहुत कम रहता है। यह आपके आवेदन को लागू करने में बहुत अक्षम है और आपके ऐप को स्केलिंग से रोकता है।

मेरा AsyncEnumerator किसी भी धागे को अवरुद्ध किए बिना एसिंक्रोनस I/O संचालन शुरू करने के बारे में है ताकि आपके ऐप का संसाधन उपयोग बहुत कम रहता है ताकि आपका ऐप बहुत अच्छा हो। इस मामले में सीपीयू उपयोग कम रहता है क्योंकि आप I/O प्रदर्शन कर रहे हैं; एक कम्प्यूटेशनल वर्कलोड नहीं।

.NET के अगले संस्करण में, नई async/प्रतीक्षा भाषा सुविधाओं (जो मैंने माइक्रोसॉफ्ट के साथ काम किया), आपको एसिंक I/O करने में सक्षम बनाता है और वास्तव में, नई विशेषताएं मेरे AsyncEnumerator के समान ही बनाई गई हैं । इतना है कि आप पोर्ट कोड कर सकते हैं जो मेरे AsyncEnumerator का उपयोग नए मॉडल में बहुत कम स्रोत कोड परिवर्तनों के साथ करता है।

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

Answer 2

.net 4.0 PLINQ ढांचे और के विभिन्न अन्य साधन भी शामिल है थ्रेडेड गणना। अधिक जानकारी के लिए

Parallel Programming in the .NET Framework देखें।

Answer 3

एक स्पष्ट यहाँ समानांतर PLINQ है, लेकिन रिक्टर खुद dismisses this: 02:27 PMquotereply पर

जेफरी रिक्टर दिसंबर 04, 2008 वे बहुत अलग हैं। समानांतर। विशेष रूप से कंप्यू-बाउंड ऑपरेशंस के सभी सीपीयू में तह मशीन में समांतर स्केलिंग में एक गुच्छा प्रदर्शन करने के बारे में है। मेरा AsyncEnumerator अधिकतर एक या अधिक समवर्ती I/O- बाध्य संचालन जारी करने के बारे में है, बिना किसी थ्रेड ब्लॉक को के लिए पूरा करने के लिए ब्लॉक किया गया है।

हालांकि

, सी # async सीटीपी उपयोगी यहाँ और अधिक उचित हो सकता है, धागा निरंतरता रही है, यानी

var bytesRead = await stream.ReadAsync(...); 
Console.WriteLine(bytesRead); // woah! we're on a different thread now! 

यहाँ

, सी # संकलक फिर से लिखते हैं await instuctions, इस तरह है कि यह एक हो जाता है चारों ओर सब कुछ मौजूदा एसिंक ऑपरेशन के लिए कॉलबैक/निरंतरता (जिसे "प्रतीक्षा करने योग्य" मान वापस करना होगा)। एक बार यह उत्पादन में हो जाने के बाद, मुझे आशा है कि यह एसिंक के कारण आंतरिक देरी के साथ कोड लिखने का एक और अधिक प्राकृतिक तरीका बन जाएगा।

Answer 4

इस सवाल Asynchronous iterator Task<IEnumerable<T>> से

:

यह क्या तुम सच में खोजे जा रहे की तरह लगता है IObservable<T> की तरह कुछ है, जो एक तरह से एक धक्का-आधारित अतुल्यकालिक IEnumerable < टी > की तरह है। IObervable < टी > के साथ काम करने के लिए LINQ-to-Objects और अधिक जैसे काम करने के लिए माइक्रोसॉफ्ट ओपन टेक्नोलॉजीज (कोड अपाचे-2.0 के तहत लाइसेंस प्राप्त कोड) (कोई संबद्धता) से Reactive Extensions, a.k.a. Rx देखें।

आईन्यूमेरेबल < टी > के साथ समस्या यह है कि वास्तव में कोई भी ऐसा नहीं है जो वास्तव में स्वयं को असीमित बनाता है। आप आरएक्स पर निर्भरता को जोड़ने के लिए नहीं करना चाहते हैं (जो वास्तव में क्या IObservable < टी > बेहतर बनाता है), इस विकल्प आप के लिए काम कर सकते हैं:

public async Task<IEnumerable<char>> TestAsync(string testString) 
{ 
    return GetChars(testString); 
} 

private static IEnumerable<char> GetChars(string testString) 
{ 
    foreach (char c in testString.ToCharArray()) 
    { 
     // do other work 
     yield return c; 
    } 
} 

हालांकि मैं ओर आकर्षित करना चाहूँगा बाहर यह जानकर कि वास्तव में क्या असीमित रूप से किया जा रहा है, आपके लक्ष्यों को पूरा करने के लिए एक बेहतर तरीका हो सकता है। आपके द्वारा पोस्ट किए गए कोड में से कोई भी वास्तव में असीमित रूप से कुछ भी नहीं करेगा, और मुझे वास्तव में पता नहीं है कि // do other work में कुछ भी अतुल्यकालिक है (इस स्थिति में, यह आपकी अंतर्निहित समस्या का समाधान नहीं है हालांकि यह आपके कोड को संकलित करेगा)।