.NET में मेमोरी बैरियर और नॉन-ब्लॉकिंग सिंक

परिचय

इस लेख में मैं कुछ डिज़ाइनों के उपयोग के बारे में बात करना चाहता हूं जो गैर-अवरोधक सिंक्रनाइज़ेशन को लागू करने के लिए उपयोग किए जाते हैं। हम वाष्पशील कीवर्ड, वोलेटाइलरीड, वोलेटाइलराइट, और मेमोरीबेरियर कार्यों के बारे में बात करेंगे। हम विचार करेंगे कि कौन सी समस्याएं हमें इन भाषा निर्माणों और उनके समाधानों का उपयोग करने के लिए मजबूर करती हैं। मेमोरी बाधाओं पर चर्चा करने में, हम .NET मेमोरी मॉडल की संक्षिप्त समीक्षा करते हैं।

संकलनकर्ता द्वारा प्रस्तुत अनुकूलन

गैर-अवरोधक सिंक्रनाइज़ेशन का उपयोग करते समय एक प्रोग्रामर का सामना करने में मुख्य समस्याएं कंपाइलर अनुकूलन और प्रोसेसर निर्देश पुनर्व्यवस्था हैं।
आइए एक उदाहरण को देखते हुए शुरू करते हैं जहां संकलक एक बहु-थ्रेडेड प्रोग्राम में एक समस्या का परिचय देता है:

class ReorderTest { private int _a; public void Foo() { var task = new Task(Bar); task.Start(); Thread.Sleep(1000); _a = 0; task.Wait(); } public void Bar() { _a = 1; while (_a == 1) { } } } 

इस उदाहरण को चलाकर, आप यह सुनिश्चित कर सकते हैं कि प्रोग्राम फ्रीज हो गया है। कारण यह है कि संकलक प्रोसेसर रजिस्टर में _a चर को कैश करता है।
ऐसी समस्याओं को हल करने के लिए, C # अस्थिर कीवर्ड प्रदान करता है। इस कीवर्ड को एक वैरिएबल पर लागू करना कंपाइलर को किसी भी तरह से एक्सेस करने के अनुकूलन से रोकता है।

यह है कि संशोधित _a चर घोषणा कैसे दिखेगी।

 private volatile int _a; 

कंपाइलर ऑप्टिमाइज़ेशन को अक्षम करना इस कीवर्ड का उपयोग करने का एकमात्र प्रभाव नहीं है। अन्य प्रभावों पर बाद में चर्चा की जाएगी।

निर्देश पुनर्व्यवस्थित करें

आइए अब हम उस मामले पर विचार करें जब समस्याओं का स्रोत प्रोसेसर द्वारा निर्देशों का पुनर्व्यवस्था है।
निम्नलिखित कोड होने दें:

 class ReorderTest2 { private int _a; private int _b; public void Foo() { _a = 1; _b = 1; } public void Bar() { if (_b == 1) { Console.WriteLine(_a); } } } 

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

.NET मेमोरी मॉडल

जैसा कि पहले ही उल्लेख किया गया है, प्रोसेसर पर निर्देशों के क्रमांकन के कारण बहु-थ्रेडेड प्रोग्राम का गलत व्यवहार हो सकता है। आइए इस समस्या पर अधिक विस्तार से विचार करें।
कोई भी आधुनिक प्रोसेसर मेमोरी को रीडायरेक्ट कर सकता है और अनुकूलन के लिए निर्देश लिख सकता है। मैं इसे एक उदाहरण से समझाऊंगा।

 int a = _a; _b = 10; 

इस कोड में, चर _a पहले पढ़ा जाता है, फिर _b लिखा जाता है। लेकिन जब इस प्रोग्राम को निष्पादित किया जाता है, तो प्रोसेसर रीड एंड राइट निर्देशों को पुनर्व्यवस्थित कर सकता है, अर्थात, चर _b को पहले लिखा जाएगा, और उसके बाद ही _a पढ़ा जाएगा। एकल-थ्रेडेड प्रोग्राम के लिए, यह क्रमपरिवर्तन कोई मायने नहीं रखता है, लेकिन बहु-थ्रेडेड प्रोग्राम के लिए, यह समस्या में बदल सकता है। अब हमने क्रमचय डाउनलोड - रिकॉर्ड की जांच की है। निर्देशों के अन्य संयोजनों के लिए समान क्रमपरिवर्तन संभव है।

ऐसे निर्देशों के लिए क्रमपरिवर्तन नियमों के सेट को मेमोरी मॉडल कहा जाता है। .NET प्लेटफ़ॉर्म का अपना मेमोरी मॉडल है, जो हमें किसी विशेष प्रोसेसर के मेमोरी मॉडल से अलग करता है।
यह .NET मेमोरी मॉडल कैसे दिखता है

क्रमचय प्रकार	परमीशन की अनुमति दी
लोड लोडिंग	हां
रिकॉर्ड डाउनलोड करें	हां
रिकॉर्डिंग डाउनलोड करें	हां
लिखने-लिखने	नहीं

अब हम .NET मेमोरी मॉडल के संदर्भ में अपने उदाहरण पर विचार कर सकते हैं। चूंकि क्रमपरिवर्तन लिखना-लिखना निषिद्ध है, तो चर _a को लिखना हमेशा चर _b पर लिखने से पहले होगा, और यहां प्रोग्राम सही तरीके से काम करेगा। समस्या बार प्रक्रिया में है। चूंकि पढ़ने के निर्देशों की अदला-बदली निषिद्ध है, इसलिए _b चर को _a से पहले पढ़ा जा सकता है।
क्रमपरिवर्तन के बाद, कोड निष्पादित किया जाएगा जैसे कि इसे निम्नानुसार लिखा गया था:

 var tmp = _a; if (_b == 1) { Console.WriteLine(tmp); } 

जब हम निर्देशों के क्रमपरिवर्तन के बारे में बात करते हैं, तो हमारा मतलब एक चर पढ़ने / विभिन्न चर लिखने से निर्देशों का क्रमांकन होता है। यदि विभिन्न थ्रेड्स में एक ही चर में एक रिकॉर्ड है, तो उनका क्रम किसी भी मामले में यादृच्छिक है। और अगर हम एक ही चर को पढ़ने और लिखने के बारे में बात कर रहे हैं, उदाहरण के लिए, इस तरह:

 var a = GetA(); UseA(a); 

फिर, ज़ाहिर है, कि यहाँ क्रमपरिवर्तन नहीं हो सकता।

स्मृति बाधाएँ

इस समस्या को हल करने के लिए, एक सार्वभौमिक विधि है - मेमोरी बैरियर (मेमोरी बैरियर) जोड़ना।
कई प्रकार की मेमोरी बाधाएं हैं: पूर्ण, रिलीज बाड़ और एक्सीर बाड़।
एक पूर्ण अवरोध यह सुनिश्चित करता है कि अवरोध के पहले / बाद में / के बाद स्थित सभी को पढ़ता है और लिखता है, अर्थात, कोई भी मेमोरी एक्सेस निर्देश अवरोध पर कूद नहीं सकता है।
अब हम दो अन्य प्रकार की बाधाओं से निपटेंगे:
Accure बाड़ यह सुनिश्चित करती है कि अवरोध के बाद निर्देश बाधा से पहले स्थिति में नहीं ले जाए।
रिलीज बाड़ यह सुनिश्चित करती है कि बाधा से पहले निर्देशों को बाधा की स्थिति में नहीं ले जाया जाए।
शब्दावली के बारे में कुछ शब्द। वाष्पशील शब्द का अर्थ है रिलीज़ बाड़ बनाने के साथ मेमोरी में लिखना। वाष्पशील शब्द का अर्थ है, एक्सीरेंस बाड़ बनाने के साथ संयोजन में मेमोरी पढ़ना।

.NET स्मृति अवरोधों के साथ काम करने के लिए निम्नलिखित तरीके प्रदान करता है:

• The Thread.MemoryBarrier () विधि एक पूर्ण मेमोरी बैरियर बनाती है
• वाष्पशील कीवर्ड क्रमशः इस शब्द के साथ चिह्नित चर पर प्रत्येक ऑपरेशन को वाष्पशील लेखन या अस्थिर पढ़ने में बदल देता है।
• Thread.VolatileRead () विधि वाष्पशील वाचन करती है
• विधि Thread.VolatileWrite () वाष्पशील लेखन करता है

आइए अपने उदाहरण पर वापस जाएं। जैसा कि हम पहले ही समझ चुके हैं, पठन निर्देश के क्रमपरिवर्तन के कारण समस्या उत्पन्न हो सकती है। इसे हल करने के लिए, रीड्स _a और _b के बीच एक मेमोरी बैरियर जोड़ें। उसके बाद, हमारे पास गारंटी है कि जिस थ्रेड में बार विधि निष्पादित की गई है वह प्रविष्टियों को सही क्रम में देखेगा।

 class ReorderTest2 { private int _a; private int _b; public void Foo() { _a = 1; _b = 1; } public void Bar() { if (_a == 1) { Thread.MemoryBarrier(); Console.WriteLine(_b); } } } 

पूर्ण मेमोरी बैरियर का उपयोग करना यहाँ बेमानी है। पढ़ने के निर्देशों के क्रमपरिवर्तन को समाप्त करने के लिए, _a पढ़ते समय अस्थिर पढ़ने का उपयोग करना पर्याप्त है। यह Thread.VolatileRead विधि या अस्थिर कीवर्ड का उपयोग करके प्राप्त किया जा सकता है।

Thread.VolatileWrite और Thread.VolatileRead विधियाँ

आइए थ्रेड पर देखें। VolatileWrite और Thread.VolatileRead के तरीकों को और अधिक विस्तार से देखें।
MSDN में VolatileWrite के बारे में यह लिखा है: "यह मान को सीधे फ़ील्ड में लिखता है, ताकि यह कंप्यूटर के सभी प्रोसेसरों को दिखाई दे।"
वास्तव में, यह विवरण पूरी तरह से सही नहीं है। ये विधियाँ दो चीजों की गारंटी देती हैं: कोई संकलक ¹ अनुकूलन और कोई निर्देश क्रमपरिवर्तन वाष्पशील पढ़ने या लिखने के गुणों के अनुसार। कड़ाई से बोलने पर, VolatileWrite विधि यह गारंटी नहीं देती है कि मूल्य तुरंत अन्य प्रोसेसर के लिए दृश्यमान हो जाएगा, और VolatileRead विधि यह गारंटी नहीं देती है कि मूल्य ² कैश से पढ़ा नहीं जाएगा। लेकिन कंपाइलर द्वारा कोड के अनुकूलन की कमी और प्रोसेसर कैश के सुसंगतता के कारण , हम यह मान सकते हैं कि एमएसडीएन से विवरण सही है।

गौर कीजिए कि ये तरीके कैसे लागू होते हैं:

 [MethodImpl(MethodImplOptions.NoInlining)] public static int VolatileRead(ref int address) { int num = address; Thread.MemoryBarrier(); return num; } [MethodImpl(MethodImplOptions.NoInlining)] public static void VolatileWrite(ref int address, int value) { Thread.MemoryBarrier(); address = value; } 

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

कंपाइलर और प्रोसेसर अनुकूलन

मैं फिर से नोट करना चाहता हूं: मेमोरी बाधाओं को स्थापित करने के लिए वाष्पशील कीवर्ड और विचारशील कार्यों के तीनों प्रोसेसर अनुकूलन और संकलक अनुकूलन दोनों को प्रभावित करते हैं।
उदाहरण के लिए, यह कोड पहले उदाहरण में दिखाई गई समस्या का पूरी तरह से सही समाधान है:

 public void Bar() { _a = 1; while (_a == 1) { Thread.MemoryBarrier(); } } 

अस्थिरता के खतरे

VolatileWrite और VolatileRead विधियों के कार्यान्वयन को देखते हुए, यह स्पष्ट हो जाता है कि इस तरह के निर्देशों की एक जोड़ी बनाई जा सकती है:

 Thread.VolatileWrite(b) Thread.VolatileRead(a) 

चूंकि यह व्यवहार अस्थिर वाचन और लिखने की शर्तों की परिभाषा में अंतर्निहित है, इसलिए यह बग नहीं है, और वाष्पशील कीवर्ड के साथ चिह्नित चर वाले संचालन का व्यवहार समान है।
लेकिन व्यवहार में, यह व्यवहार अप्रत्याशित हो सकता है।
एक उदाहरण पर विचार करें:

 class Program { volatile int _firstBool; volatile int _secondBool; volatile string _firstString; volatile string _secondString; int _okCount; int _failCount; static void Main(string[] args) { new Program().Go(); } private void Go() { while (true) { Parallel.Invoke(DoThreadA, DoThreadB); if (_firstString == null && _secondString == null) { _failCount++; } else { _okCount++; } Console.WriteLine("ok - {0}, fail - {1}, fail percent - {2}", _okCount, _failCount, GetFailPercent()); Clear(); } } private float GetFailPercent() { return (float)_failCount / (_okCount + _failCount) * 100; } private void Clear() { _firstBool = 0; _secondBool = 0; _firstString = null; _secondString = null; } private void DoThreadA() { _firstBool = 1; //Thread.MemoryBarrier(); if (_secondBool == 1) { _firstString = "a"; } } private void DoThreadB() { _secondBool = 1; //Thread.MemoryBarrier(); if (_firstBool == 1) { _secondString = "a"; } } } 

यदि प्रोग्राम निर्देशों को उस सटीक क्रम में निष्पादित किया गया था जिसमें वे परिभाषित किए गए थे, तो कम से कम एक पंक्ति हमेशा "ए" के बराबर होगी। वास्तव में, निर्देशों के पुनर्व्यवस्था के कारण, यह हमेशा ऐसा नहीं होता है। वाष्पशील कीवर्ड को उचित तरीकों से प्रतिस्थापित करना, जैसा कि अपेक्षित है, परिणाम को नहीं बदलता है।
इस कार्यक्रम के व्यवहार को ठीक करने के लिए, यह पूर्ण मेमोरी बाधाओं के साथ लाइनों को अनियंत्रित करने के लिए पर्याप्त है।

प्रदर्शन थ्रेड। अस्थिर * और अस्थिर कीवर्ड

अधिकांश प्लेटफार्मों पर (अधिक सटीक रूप से, विंडोज द्वारा समर्थित सभी प्लेटफार्मों पर, मरने वाले IA64 को छोड़कर), सभी लिखते हैं और पढ़ते हैं क्रमशः वाष्पशील लेखन और वाष्पशील रीड। इस प्रकार, रन टाइम में, वाष्पशील कीवर्ड का प्रदर्शन पर कोई प्रभाव नहीं पड़ता है। इसके विपरीत, Thread.Volatile * विधियाँ, सबसे पहले, विधि कॉल पर स्वयं ओवरहेड, MethodImplOptions.NoInlining के रूप में चिह्नित की जाती है, और दूसरी बात, वर्तमान कार्यान्वयन में, वे एक पूर्ण मेमोरी बैरियर बनाते हैं। यही है, प्रदर्शन के मामले में, ज्यादातर मामलों में, कीवर्ड का उपयोग बेहतर होता है।

---

संदर्भ

¹ पेज 514 जो डफी देखें। खिड़कियों पर समवर्ती प्रोग्रामिंग
² देखें VolatileWrite को गलत तरीके से लागू किया गया

प्रयुक्त साहित्य:

1. जोसेफ अलबहारी। C # में थ्रेडिंग
2. वेंस मॉरिसन मल्टीथ्रेडेड ऐप्स में लो-लॉक तकनीकों के प्रभाव को समझें
3. पेड्रम रेज़ाई। सीएलआर 2.0 मेमोरी मॉडल
4. एमएस कनेक्ट: VolatileWrite गलत तरीके से लागू किया गया
5. ECMA-335 आम भाषा इंफ्रास्ट्रक्चर (सीएलआई)
6. सी # भाषा विशिष्टता
7. जेफरी रिक्टर C # तीसरे संस्करण के माध्यम से सीएलआर
8. जो डफी। खिड़कियों पर समवर्ती प्रोग्रामिंग
9. जोसेफ अलबहारी। संक्षेप में सी # 4.0