टाइमर .Net में

हाल ही में, यह पहली बार है जब मैं इस तथ्य के बारे में आया हूं कि डेवलपर्स पूरी तरह से यह नहीं समझते हैं कि .NET के मानक मानक में से एक कैसे काम करता है - System.Threading.Timer।
यानी सामान्य तौर पर, वे इस तरह की समझ रखते हैं कि टाइमर कुछ कर रहा है, थ्रेडपूल में सबसे अधिक संभावना है - और यदि आप इसका उपयोग समय-समय पर कुछ निष्पादित करने के लिए करते हैं, तो यह काफी उपयुक्त है। लेकिन अगर आपको एक से अधिक टाइमर बनाने, और 1000 डालने की आवश्यकता है, तो लोग चिंता करना शुरू कर देते हैं: क्या होगा अगर वहाँ कुछ गलत है, लेकिन अचानक यह अभी भी 1000 धागे हैं और वे ऐसे मामलों में उनका उपयोग करने से भी डरते हैं।

मैं इस "रहस्यमय" System.Threading.Timer पर कुछ प्रकाश डालना चाहूंगा।

अन्य टाइमर अभी भी .NET में मौजूद हैं, लेकिन वे मुख्य रूप से विशिष्ट समस्याओं को हल करने के लिए डिज़ाइन किए गए हैं (उदाहरण के लिए, GUI अनुप्रयोग लिखने के लिए)। हम इस पर विचार कर रहे हैं कि इसका उद्देश्य "सिस्टम" की समस्याओं को हल करना है या पुस्तकालयों में उपयोग करना है।

थोड़ा सा हम कैसे एक टाइमर को लागू कर सकते हैं के बारे में।

उदाहरण के लिए, हम काम की प्रत्येक समय-समय पर निष्पादित इकाई के लिए एक अलग थ्रेड बना सकते हैं जो एक निश्चित अंतराल के बाद उठता है, काम करता है और फिर से सो जाता है। यह स्पष्ट है कि यह सबसे अच्छा विकल्प नहीं है।

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

WaitHandle.WaitAny(/*timerHandles[]*/) 

लेकिन, दुर्भाग्य से या नहीं, .NET में ऐसी वस्तुओं (कर्नेल टाइमर) के साथ सीधे काम करने के लिए कोई एपीआई नहीं है।

एक तीसरा टाइमर कार्यान्वयन विकल्प है (System.Threading.Timer वर्ग के डेवलपर्स से प्राप्त)
पी / इनवोक तंत्र के माध्यम से एप्लिकेशन डोमेन में पहला टाइमर बनाते समय, एक "टाइमर" कर्नेल ऑब्जेक्ट बनाया जाता है। यह System.Threading.TimerQueue वर्ग में देखा जा सकता है:

  [SecurityCritical] [SuppressUnmanagedCodeSecurity] [DllImport("QCall", CharSet = CharSet.Unicode)] private static TimerQueue.AppDomainTimerSafeHandle CreateAppDomainTimer(uint dueTime); // some code if (this.m_appDomainTimer == null || this.m_appDomainTimer.IsInvalid) { this.m_appDomainTimer = TimerQueue.CreateAppDomainTimer(dueTime); // some code 

यह एक अलग थ्रेड भी बनाता है जो गणना करता है कि आपको आग लगाने के लिए अगले टाइमर के लिए कितना इंतजार करना होगा, कर्नेल ऑब्जेक्ट के लिए "टाइमर" सेट करता है और इंतजार करता है।
आइए देखें कि यह कैसा दिखता है। कंसोल प्रोजेक्ट बनाएं और SOS डीबगिंग एक्सटेंशन को सक्षम करें।



जैसा कि हम देखते हैं, टाइमर बनाने से पहले, हमारे पास केवल दो धागे हैं: "मुख्य" और "फाइनल" धागा। एक लाइन नीचे चलते हैं।



हमें दो धागे मिले - एक, आईडी 3, यह ठीक वही धागा है जो कर्नेल ऑब्जेक्ट "टाइमर" के साथ काम करता है। और दूसरा एक, आईडी 4, पूल वर्कफ़्लो है, इसे अभी शुरू करने का समय नहीं हुआ है, यह हमारे कॉलबैक को निष्पादित करेगा।

अब यह सब कैसे काम करता है यदि आप क्रमिक रूप से कई टाइमर बनाते हैं
System.Threading.TimerQueue वर्ग में वापस लौटना। वह एक सिंगलटन हैं। हर बार जब आप फॉर्म का एक कोड लिखते हैं:

  new Timer(First, null, 0, 250); 

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

आइए 1000 टाइमर बनाने की कोशिश करें और देखें कि क्या होता है:



हम देखते हैं कि १००० टाइमर बनाने से १००० धागे पैदा नहीं होते। सीएलआर ने कर्नेल टाइमर के साथ काम करने के लिए एक धागा बनाया और टाइमर के संचालन से निपटने के लिए कई कार्यकर्ता धागे।

कुल:
जब आप System.Threading.Timer वर्ग के साथ काम करते हैं, तो आप एक (प्रति एप्लिकेशन डोमेन) कर्नेल ऑब्जेक्ट "टाइमर" और इसके साथ काम करने के लिए एक धागा बनाते हैं जो "हीप" डेटा संरचना के काम के समान सिद्धांत पर काम करता है।
1000 टाइमर के सवाल पर - क्या आवेदन में इतनी संख्या में टाइमर बनाने के लिए यह लाभहीन है, मुझे लगता है कि प्रत्येक विशिष्ट मामले पर अलग से विचार किया जाना चाहिए। लेकिन यह जानना कि समय के अंदर व्यवस्था कैसे की जाती है, इससे आपको सही निर्णय लेने में मदद मिलेगी।

विंडोज 7 64, .net 4.5, VS2012 पर परीक्षण किया गया।
संदर्भ: डफी "विंडोज पर समवर्ती प्रोग्रामिंग", एमएसडीएन