क्या गंभीर अनुभाग हमेशा तेज है?

Question

मैं एक बहु थ्रेडेड अनुप्रयोग डीबग कर रहा था और CRITICAL_SECTION की आंतरिक संरचना पाई। मुझे CRITICAL_SECTION के डेटा सदस्य LockSemaphore को एक दिलचस्प व्यक्ति मिला।

ऐसा लगता है कि LockSemaphore एक ऑटो-रीसेट ईवेंट है (नाम के रूप में एक सेमफोर नहीं है) और ऑपरेटिंग सिस्टम चुपचाप इस घटना को बनाता है जब पहली बार थ्रेड Critcal Section पर प्रतीक्षा करता है जो किसी अन्य थ्रेड द्वारा लॉक किया जाता है।

अब, मुझे आश्चर्य है कि गंभीर अनुभाग हमेशा तेज है? इवेंट एक कर्नेल ऑब्जेक्ट है और प्रत्येक क्रिटिकल सेक्शन ऑब्जेक्ट इवेंट ऑब्जेक्ट से जुड़ा हुआ है, तो Critical Section म्यूटेक्स जैसी अन्य कर्नेल ऑब्जेक्ट्स की तुलना में तेज़ी से कैसे हो सकता है? साथ ही, आंतरिक घटना वस्तु वास्तव में गंभीर खंड के प्रदर्शन को कैसे प्रभावित करती है?

struct RTL_CRITICAL_SECTION 
{ 
    PRTL_CRITICAL_SECTION_DEBUG DebugInfo; 
    LONG LockCount; 
    LONG RecursionCount; 
    HANDLE OwningThread; 
    HANDLE LockSemaphore; 
    ULONG_PTR SpinCount; 
}; 

Answer 1

जब वे कहते हैं कि एक महत्वपूर्ण खंड "तेज़" है, तो उनका मतलब है "यह किसी अन्य थ्रेड द्वारा पहले से लॉक नहीं होने पर एक अधिग्रहण करना सस्ता है"।

[ध्यान दें कि अगर यह पहले से ही एक और धागा द्वारा बंद कर दिया है, तो यह बात लगभग इतना है कि यह कैसे तेज है नहीं करता है।]

कारण है कि यह तेजी से है, क्योंकि, कर्नेल में जाने से पहले , यह उन LONG फ़ील्ड (शायद LockCount फ़ील्ड पर) पर InterlockedIncrement के समतुल्य का उपयोग करता है (यदि LockCount फ़ील्ड पर) और यदि यह सफल होता है तो यह कर्नेल में घुसने के बिना लॉक को एक्वार्ड किया जाता है।

InterlockedIncrement एपीआई मुझे लगता है कि उपयोगकर्ता मोड में "लॉक इंक" ओपोड के रूप में लागू किया गया है ... दूसरे शब्दों में आप कर्नेल में किसी भी अंगूठी संक्रमण के बिना एक अनचाहे महत्वपूर्ण अनुभाग प्राप्त कर सकते हैं।

Answer 2

CriticalSections कुछ समय (कुछ एमएस) स्पिन और जाँच अगर ताला नि: शुल्क है रखेंगे:

यहाँ CRITICAL_SECTION की संरचना है। स्पिन गिनती के बाद 'टाइम्स आउट' के बाद, यह कर्नेल घटना पर वापस आ जाएगा। तो ऐसे मामले में जहां लॉक धारक जल्दी से बाहर हो जाता है, आपको कर्नेल कोड में महंगी संक्रमण कभी नहीं करना पड़ता है।

संपादित करें: चला गया और मेरे कोड में कुछ टिप्पणी नहीं मिली: जाहिरा तौर पर एमएस ढेर प्रबंधक 4000 की एक स्पिन गिनती (पूर्णांक वेतन वृद्धि, नहीं एमएस)

Answer 3

प्रदर्शन काम में, कुछ बातें "हमेशा" श्रेणी में आते हैं का उपयोग करता है :) यदि आप स्वयं को कुछ लागू करते हैं जो कि अन्य प्राइमेटिव्स का उपयोग करते हुए एक ओएस महत्वपूर्ण खंड के समान है तो बाधाएं ज्यादातर मामलों में धीमी हो जाएंगी।

प्रदर्शन प्रश्न के साथ आपके प्रश्न का उत्तर देने का सबसे अच्छा तरीका है। ओएस ऑब्जेक्ट्स कैसे प्रदर्शन करते हैं बहुत परिदृश्य पर निर्भर करता है। उदाहरण के लिए, यदि विवाद कम है तो महत्वपूर्ण वर्गों को आम तौर पर 'तेज़' माना जाता है। यदि लॉक टाइम स्पिन गिनती समय से कम है तो उन्हें भी तेज़ माना जाता है।

यह निर्धारित करने के लिए सबसे महत्वपूर्ण बात यह है कि यदि किसी महत्वपूर्ण अनुभाग पर विवाद आपके आवेदन में पहला आदेश सीमित कारक है। यदि नहीं, तो बस एक महत्वपूर्ण अनुभाग normaly का उपयोग करें और अपने अनुप्रयोगों प्राथमिक प्राथमिक बाधा (या गर्दन) पर काम करते हैं।

यदि महत्वपूर्ण अनुभाग प्रदर्शन महत्वपूर्ण है, तो आप निम्न पर विचार कर सकते हैं।

1. सावधानीपूर्वक अपने 'गर्म' महत्वपूर्ण वर्गों के लिए स्पिन लॉक गिनती सेट करें। यदि प्रदर्शन सर्वोपरि है, तो यहां का काम इसके लायक है। याद रखें, जबकि स्पिन लॉक उपयोगकर्ता मोड से कर्नेल संक्रमण से बचता है, यह सीपीयू समय को एक क्रूर दर पर खपत करता है - कताई करते समय, सीपीयू समय का उपयोग करने के लिए और कुछ नहीं मिलता है। यदि एक लॉक काफी लंबे समय तक आयोजित किया जाता है, तो कताई धागा वास्तविक ब्लॉक होगा, जो उस सीपीयू को अन्य काम करने के लिए मुक्त कर देगा।
2. यदि आपके पास पाठक/लेखक पैटर्न है तो Slim Reader/Writer (SRW) locks का उपयोग करने पर विचार करें। यहां नकारात्मकता यह है कि वे केवल Vista और Windows Server 2008 और बाद के उत्पादों पर उपलब्ध हैं।
3. आप मतदान और विवाद को कम करने के लिए अपने महत्वपूर्ण अनुभाग के साथ condition variables का उपयोग करने में सक्षम हो सकते हैं, केवल आवश्यक होने पर धागे जागते हैं। फिर, ये Vista और Windows Server 2008 और बाद के उत्पादों पर समर्थित हैं।
4. Interlocked Singly Linked Lists (SLIST) का उपयोग करने पर विचार करें - ये कुशल हैं और 'लॉक फ्री' हैं। इससे भी बेहतर, वे XP और Windows Server 2003 और बाद के उत्पादों पर समर्थित हैं।
5. अपने कोड की जांच करें - आप कुछ कोड को दोबारा और एक इंटरलॉक ऑपरेशन या सिंक्रनाइज़ेशन और संचार के लिए एसएलआईटीटी का उपयोग करके 'हॉट' लॉक तोड़ने में सक्षम हो सकते हैं।

सारांश में - लॉक विवाद वाले ट्यूनिंग परिदृश्य चुनौतीपूर्ण (लेकिन दिलचस्प!) काम हो सकते हैं। अपने अनुप्रयोगों के प्रदर्शन को मापने और अपने गर्म पथ कहां समझने पर ध्यान केंद्रित करें। Windows Performance Tool kit में xperf टूल्स आपका मित्र है :) हमने अभी विंडोज 7 के लिए माइक्रोसॉफ्ट विंडोज एसडीके में संस्करण 4.5 और .NET Framework 3.5 SP1 (ISO is here, web installer here) जारी किया है। आप xperf टूल्स here के लिए फोरम पा सकते हैं। V4.5 पूरी तरह से Win7, Vista, Windows Server 2008 - सभी संस्करणों का समर्थन करता है।

Answer 4

गंभीर संरचनाएं तेज हैं, लेकिन InterlockedIncrement/InterlockedDecrement अधिक है। इस कार्यान्वयन उपयोग नमूना LightweightLock full copy देखें।

कोई विवाद नहीं है, तो स्पिन ताला वास्तव में तेजी से एक Mutex के लिए मोड कर्नेल के लिए जा रहा की तुलना में है:

Answer 5

यहाँ एक तरह से इस पर गौर करने के लिए है।

जब विवाद होता है, तो एक क्रिटिकलसेक्शन सीधे म्यूटक्स का उपयोग करने से थोड़ा महंगा होता है (स्पिनलॉक स्थिति का पता लगाने के लिए अतिरिक्त कार्य के कारण)।

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

Answer 6

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