मेरे BeginInvoke()/EndInvoke() प्रश्न से निम्नलिखित प्रदर्शन में/प्रतिनिधि के बीच कुछ और अंतर हैं। BeginInvoke() और QueueUserWorkItem() का उपयोग करके एक प्रतिनिधि को अतुल्यकालिक रूप से आमंत्रित करने के लिए?QueueUserWorkItem() और BeginInvoke() के बीच कोई अंतर नहीं है, बिना किसी रिटर्न प्रकार वाले एसिंक्रोनस गतिविधि करने के लिए
http://blogs.msdn.com/cbrumme/archive/2003/07/14/51495.aspx
का कहना है:
"एक आश्चर्य की बात यह है कि इस भी कारण है कि Delegate.BeginInvoke/ EndInvoke बराबर (या ThreadPool.QueueUserWorkItem तरह तकनीकों की तुलना में कर रहे हैं ताकि धीमी है UnsafeQueueUserWorkItem यदि आप सुरक्षा प्रभावों को समझते हैं और वास्तव में कुशल होना चाहते हैं) BeginInv के लिए codepath ओके/एंडइवोक सामान्य सामान्य रीमोटिंग मार्ग के प्रोसेसिंग कोड में तुरंत बदल जाता है। "
हमम, धन्यवाद, यह दिलचस्प और बहुत डरावना दोनों है। मुझे लगता है कि मैं किसी भी BeginInvoke()/EndInvoke() कोड को वापस रोल करूंगा जिसके लिए वापसी मूल्यों की आवश्यकता नहीं है! – endian
मुख्य बात मैं QueueUserWorkItem साथ के बारे में सोच सकते हैं कि आप अगर आप पहले से ही एक SomeRandomDelegate उदाहरण और कुछ आर्ग है WaitCallback प्रतिनिधि प्रकार है, जो लग रहा है मुश्किल का उपयोग करना होगा है। अच्छी खबर यह है कि आप एक बंद के साथ इसे ठीक कर सकते है:
ThreadPool.QueueUserWorkItem(
delegate { someDelegate(arg1, arg2); }
);
यह पैटर्न भी सुनिश्चित करता है आप संकलन समय पर (QueueUserWorkItem के लिए एक object राज्य आर्ग गुजर और लक्ष्य विधि में यह कास्टिंग के विपरीत) उचित मजबूत टाइपिंग मिलता है। जब तरीकों को सीधे फ़ोन यह पैटर्न का भी इस्तेमाल किया जा सकता है:
ThreadPool.QueueUserWorkItem(
delegate { SomeMethod(arg1, arg2); }
);
जाहिर है, बिना एक EndInvoke बराबर, आप भी नहीं एक वापसी मान वापस बाहर निकल सकते हैं जब तक आप एक विधि कॉल/अंत में एक घटना/आदि बढ़ा आपकी विधि का ... संबंधित नोट पर, आपको exception handling से सावधान रहना होगा।
इस सटीक परिदृश्य का मुकाबला पहली बार मैंने खुद को सोचा था, "वाह, मुझे प्यार है बंद। " –
वाह, यह एक सर्वोच्च टिप है। यह एक मुक्केबाजी/अनबॉक्सिंग अर्थपूर्ण की तरह लगता है, और मैं चीजों की व्यापक योजना में, और अधिक महंगा नहीं सोचता हूं। –
ओह, तकनीकी रूप से, यह कोड को संकलित करने के लिए "प्रतिनिधि (ऑब्जेक्ट ओ)" या समान होना चाहिए, मेरा मानना है कि चूंकि QueueUserWorkItem एक प्रतिनिधि हस्ताक्षर की अपेक्षा करता है जो प्रतीक्षाकॉलबैक से मेल खाता है, यानी, जिसमें ऑब्जेक्ट का एक पैरामीटर शामिल है। –
कोई बड़ा अंतर नहीं होना चाहिए, मुझे यह भी लगता है कि एक प्रतिनिधि के लिए उत्पन्न BeginInvoke/EndInvoke निष्पादित करने के लिए थ्रेड पूल का उपयोग करता है।
कोई प्रदर्शन अंतर नहीं होना चाहिए, दोनों प्रतिनिधिमंडल के रूप में। BginginInvoke और ThreadPool.QueueUserWorkItem थ्रेड पूल थ्रेड पर निष्पादित होगा।
सबसे बड़ा अंतर यह है कि यदि आप BeginInvoke को कॉल करते हैं, तो आप किसी बिंदु पर EndInvoke को कॉल करने के लिए बाध्य हैं। इसके विपरीत, ThreadPool.QueueUserWorkItem "आग और भूल" है। इसका लाभ और कमी है। लाभ यह है कि आप इसके बारे में भूल सकते हैं। इस बात की कमी यह है कि जब तक कार्य पूरा नहीं हो जाता है, तब तक जब तक आप अपना स्वयं का सिंक्रनाइज़ेशन/अधिसूचना तंत्र नहीं जोड़ते, तब तक आपको जानने का कोई तरीका नहीं है।
EndInvoke() एक उपयोगी लेकिन शायद ही कभी उल्लेख व्यवहार है - यह सब बिना क्रिया अपवाद rethrows कि प्रतिनिधि मूल थ्रेड के संदर्भ में उत्पन्न ताकि आप मुख्य कोड में अपवाद संसाधन तर्क स्थानांतरित कर सकते हैं।
इसके अलावा, यदि आपके प्रतिनिधि के पास आउटपुट/आउट पैरामीटर हैं, तो उन्हें एंडइनवोक() हस्ताक्षर में जोड़ा जाएगा जब आप निष्पादन समाप्त करते समय उन्हें प्राप्त करने की अनुमति देते हैं।
बहुत धन्यवाद, मुझे यह नहीं पता था – endian
यदि आप थ्रेडपूल को कॉल करते हैं।QueueUserWorkItem, कार्य आइटम में उठाए गए अपवाद पृष्ठभूमि थ्रेड पर अनचाहे किए जाएंगे (जब तक कि आप उन्हें स्पष्ट रूप से पकड़ न लें)। .Net 2 और इससे ऊपर में यह आपके ऐपडोमेन को समाप्त कर देगा।
यदि आप प्रतिनिधि को कॉल करते हैं। बेगिन इनवोक() तो एंडइवोक() कहा जाता है तो अपवादों को फिर से फेंकने के लिए कतारबद्ध किया जाता है। यदि आप EndInvoke() को कभी भी कॉल नहीं करते हैं, तो अपवाद अनिवार्य रूप से 'लीक' मेमोरी हैं (जैसा कि एसिंक ऑपरेशन द्वारा जारी नहीं किया गया कोई अन्य राज्य है)।
आप यह भी देखना चाहेंगे: http://marcgravell.blogspot.com/2009/02/async-without-pain.html –