सी # कार्य कॉन्फ़िगरएवेट

Question

सोचा था कि मुझे ConfigureAwait पर एक हैंडल मिल रहा था, फिर मैंने एक प्रयोग करने की कोशिश की।

मेरी समझ यह है कि ConfigureAwait(false) सिंक्रनाइज़ेशन संदर्भ होने पर केवल तभी अंतर आएगा।

एएसपी, डब्ल्यूपीएफ, आदि का एक संदर्भ होना चाहिए, लेकिन कंसोल ऐप्स और सेवा ऐप्स नहीं होना चाहिए।

// GET api/values/5 
public async Task<string> Get (int id) 
{ 
    var syncCtx = SynchronizationContext.Current; 

    int startThreadId = Thread.CurrentThread.ManagedThreadId; 

    await Task.Delay(TimeSpan.FromSeconds(3)).ConfigureAwait(true); 

    int endThreadId = Thread.CurrentThread.ManagedThreadId; 

    return "Start Thread ID: " + startThreadId.ToString() + 
      ": End Thread ID: " + endThreadId.ToString(); 
} 

मेरे भविष्यवाणी थी कि true करने के लिए कोई ConfigureAwait या ConfigureAwait सेट के साथ, मैं एक ही धागा आईडी से पहले देखना चाहिए और:

यह कैसे काम करता है मैं एक वेब API एप्लिकेशन बनाया है और शामिल निम्न विधि को देखने के लिए प्रतीक्षा के बाद।

मेरे पहले कुछ परीक्षणों ने दिखाया कि ऊपर के रूप में सही सेट के साथ।

कोड के बाद के रन ConfigureAwait पर ध्यान दिए बिना अलग थ्रेड आईडी पर समाप्त हो गए।

मैंने खुद को मनाने के लिए syncCtx जोड़ा है मेरे पास एक संदर्भ है।

मैंने जो चेतावनी पढ़ी है वह यह है कि यदि कार्य पूरा हो गया है, तो आपको उसी आईडी की गारंटी नहीं दी जाएगी। क्या यह मामला यहाँ है? यदि हां, तो वह मामला क्यों है?

क्या मैंने एक बेवकूफ या दोषपूर्ण परीक्षण स्थापित किया है? यदि हां, तो उचित परीक्षा क्या होगी?

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

Answer 1

ConfigureAwait(true) (या इसे छोड़कर, इसे डिफ़ॉल्ट मान के रूप में छोड़कर) इसे उसी धागे पर नहीं चलाता है। यह SynchronizationContext.Current को Post या Send को शेष निरंतरता के साथ करने के लिए बताता है। पोस्ट या भेज वास्तव में कैसे चलाता है कि कोड परिभाषित नहीं किया गया है।

WindowsFormsSynchronizationContext और DispatcherSynchronizationContext (विनफॉर्म और डब्ल्यूपीएफ के संदर्भ) दोनों संदेश पंप (यूआई थ्रेड) द्वारा संसाधित किए जाने वाले संदेशों की कतार पर निरंतरता को जारी रखेंगे।

दूसरी तरफ, AspNetSynchronizationContext (जो आप नीचे चल रहे हैं) बस कुछ राज्य जानकारी सेट करता है (जैसे HttpContext.Current को अपने पुराने मान पर वापस सेट करना), फिर यह अगले उपलब्ध थ्रेड पूल थ्रेड पर काम कतारबद्ध करता है। एएसपी.नेट के लिए कोई "संदेश पंप" नहीं है, यह सिर्फ थ्रेड पूल पर अपने सभी काम करता है, इसलिए बाद में थ्रेड पूल से एक ही थ्रेड को निकालने का प्रयास करने में कोई बात नहीं है, वह धागा पहले से ही हो सकता है निरंतरता के समय तक नष्ट हो गया।

बार आप से पहले एक ही आईडी को देखा और बाद तुम सिर्फ भाग्यशाली है और एक ही धागे से पहले और निरंतरता के बाद थ्रेड पूल से बाहर निकल गई हो गई।

मैं आपको एमएसडीएन पत्रिका लेख "It's All About the SynchronizationContext" पढ़ने की अत्यधिक अनुशंसा करता हूं, यह समझाता है कि सिंक्रनाइज़ेशन कॉन्टेक्स्ट कैसे काम करता है और .NET में बनाए गए 4 प्रकार के संदर्भों के बारे में थोड़ी सी जानकारी में जाता है।

Answer 2

SynchronizationContext! = Thread। यदि आप अपने Dispatcher रनटाइम के साथ WPF की तरह कुछ उपयोग कर रहे थे, तो हाँ, इसकेSynchronizationContext एक विशिष्ट थ्रेड से बंधे होते हैं। हालांकि एएसपी.नेट और डब्ल्यूसीएफ जैसी चीजें थ्रेड एफ़िन नहीं हैं, वे सिर्फ उनके साथ विशिष्ट परिवेश संदर्भ लेते हैं जिन्हें अगले थ्रेड पर जो भी थ्रेड निष्पादित करना शुरू होता है उसे पुनर्स्थापित करने की आवश्यकता होती है। वे एक विशिष्ट धागे पूल पर गठबंधन हो सकते हैं, लेकिन फिर, एक विशिष्ट धागा नहीं।

यही कारण है कि SynchronizationContext अमूर्तता पेश की गई थी: यह विभिन्न ढांचे को यह तय करने की अनुमति देता है कि वास्तव में उनके साथ क्या संबंध है और एसिंक/पूरी तरह से अज्ञेय तरीके से एसिंक/उनके बुनियादी ढांचे को उनके ऊपर काम करने की अनुमति देता है।