🏦 🚝 🎟️ सी ++ में सुरक्षित आलसी प्रारंभिक सूत्र 🦀 ✋🏾 🙏🏻

रेमंड चेन ने लॉकलेस सिंक्रोनाइज़ेशन के बारे में ब्लॉग पोस्टों की एक मनोरंजक श्रृंखला लिखी। मैं इन नोटों को हैब्रेक्टिकम के लिए प्रकाशित करना चाहूंगा। यह पोस्ट श्रृंखला का एक परिचय है, जो चेन के तीन पुराने पदों से संकलित है।

C ++ बिल्ट-इन के साथ आलसी इनिशियलाइज़ेशन
लॉकलेस सिंक्रनाइज़ेशन
लॉकलेस थ्रेड-सुरक्षित आलसी आरंभीकरण

C ++ बिल्ट-इन के साथ आलसी इनिशियलाइज़ेशन

C ++ में स्थैतिक स्थानीय चर का प्रारंभ थ्रेड सुरक्षित नहीं है, और जानबूझकर!

विनिर्देशन ने स्थापित किया कि स्थैतिक स्थानीय चर (वैश्विक विरोध के अनुसार) को पहली बार कोड ब्लॉक को आरम्भ किया जाता है जिसमें उन्हें घोषित किया जाता है।

कोड टुकड़े में उड़ान की स्थिति को स्वयं खोजने की कोशिश करें जो पहले कॉल पर कुछ फ़ंक्शन "लेज़ीली" के परिणाम की गणना करता है, और फिर बाद के कॉल के लिए इस परिणाम को बचाता है।

int ComputeSomething()
{
static int cachedResult = ComputeSomethingSlowly();
return cachedResult;
}

(लोकप्रिय सी ++ एफएक्यू में लगभग इस तरह के कोड की सलाह दी जाती है, ताकि वैश्विक स्थैतिक चर के आरंभ के संकलक के आदेश पर निर्भर न हो।)

बात यह है कि संकलक स्थैतिक स्थानीय चर के आरंभीकरण को इस तरह से बदल देता है:

int ComputeSomething()
{
static bool cachedResult_computed = false;
static int cachedResult;
if (!cachedResult_computed) {
cachedResult_computed = true;
cachedResult = ComputeSomethingSlowly();
}
return cachedResult;
}

अब एयर कंडीशनिंग नग्न आंखों को दिखाई देती है। एक ही समय में ComputeSomething() को कॉल करने वाले दो थ्रेड्स की कल्पना करें। पहले धागे में केवल cachedResult_computed = true निष्पादित करने का समय है cachedResult_computed = true दूसरे थ्रेड में सिस्टम स्विच करने से पहले cachedResult_computed = true । अब दूसरा थ्रेड cachedResult_computed फ्लैग cachedResult_computed देखता है, वैरिएबल इनिशियलाइज़ेशन को छोड़ देता है, और इसकी अनइंस्टाल्ड वैल्यू लेता है।

और यह संकलक में बग नहीं है - यह सी ++ मानक द्वारा निर्धारित किया गया था । (तब, TC1 संस्करण में, थ्रेड सुरक्षा आवश्यकता को हटा दिया गया था, जो एक ही समय में प्रारंभ किए जाने के मामले में "अपरिभाषित व्यवहार" को छोड़ देता है।)

स्थैतिक स्थानीय चर के बहुपरत आरंभिककरण से और अधिक महत्वपूर्ण समस्याएं हो सकती हैं:

class Something { ... };
int ComputeSomething()
{
static Something s;
return s.ComputeIt();
}

ऐसा कोड सामने आएगा

class Something { ... };
int ComputeSomething()
{
static bool s_constructed = false;
static uninitialized Something s;
if (!s_constructed) {
s_constructed = true;
new(&s) Something; // s
atexit(DestructS);
}
return s.ComputeIt();
}
// s
void DestructS()
{
ComputeSomething::s.~Something();
}

अब कई संभावित एयर कंडीशनिंग हैं। पहले की तरह, थ्रेड्स में से एक दूसरे से आगे निकल सकता है, और प्रारंभ होने से पहले s के मूल्य को पकड़ो। लेकिन इसके अलावा, यदि पहला थ्रेड s_constructed मान की जांच करने में कामयाब रहा, लेकिन इसे true पर सेट करने का प्रबंधन नहीं किया , तो s ऑब्जेक्ट दो बार बनाया जाएगा और दो बार नष्ट हो जाएगा । (बल्कि, एक ऑब्जेक्ट "लीक", और दूसरा दो बार नष्ट हो जाता है।) कोई चुटकुले नहीं!

लेकिन यह सब नहीं है। देखो कि क्या होता है अगर दो प्रारंभिक स्थिर स्थानीय चर हैं:

int ComputeSomething()
{
static Something s(0);
static Something t(1);
return s.ComputeIt() + t.ComputeIt();
}

मेमोरी को बचाने के लिए, कंपाइलर दोनों झंडों को एक चर में बचाएगा।

class Something { ... };
int ComputeSomething()
{
static char constructed = 0;
static uninitialized Something s;
if (!(constructed & 1)) {
constructed |= 1;
new(&s) Something; // s
atexit(DestructS);
}
static uninitialized Something t;
if (!(constructed & 2)) {
constructed |= 2;
new(&t) Something; // t
atexit(DestructT);
}
return s.ComputeIt() + t.ComputeIt();
}

खैर, अब हमारे पास बिना किसी तुल्यकालन के सामान्य चर पर तार्किक संचालन करने वाले कई सूत्र हैं। आइए देखें कि क्या होता है जब एक धागा constructed |= 1 को निष्पादित करने की कोशिश करता है constructed |= 1 उसी समय जब दूसरा धागा निष्पादित होता है constructed |= 2 |

X86 / x64 प्रोसेसर के निर्देश हैं जो सीधे मेमोरी में ओपेरा के साथ काम करते हैं। कंपाइलर मशीन कोड जनरेट करेगा

or constructed, 1
...
or constructed, 2

lock उपसर्गों के बिना, इसलिए मल्टीप्रोसेसर मशीनों पर दोनों ऑपरेशनों में समान पुराने मूल्य को पढ़ने का समय हो सकता है, और सेट बिट्स में से एक "खो" जाएगा।

Ia64 / अल्फा प्रोसेसर में, तार्किक निर्देश केवल रजिस्टरों के साथ काम करते हैं, इसलिए यह एकल-प्रोसेसर मशीन पर भी हो सकता है। संकलक प्रत्येक ऑपरेशन को विभाजित करता है |= तीन मशीन निर्देशों में:

ldl t1,0(a0) ;
addl t1,1,t1 ;
stl t1,1,0(a0) ;

यदि पुराने मूल्य को पढ़ने और एक नया लिखने के बीच एक थ्रेड का निष्पादन बाधित होता है, तो नया मूल्य अन्य थ्रेड्स से किए गए परिवर्तनों को "अधिलेखित" कर सकता है।

यह महत्वपूर्ण खंड द्वारा स्थैतिक चर के आरंभ की रक्षा करने के लायक हो सकता है:

int ComputeSomething()
{
EnterCriticalSection(...);
static int cachedResult = ComputeSomethingSlowly();
LeaveCriticalSection(...);
return cachedResult;
}

प्रारंभ में अब एक बार में केवल एक धागा द्वारा प्रदर्शन किया जा सकता है।

लेकिन क्या होगा अगर ComputeSomething() को उसी धागे से फिर से बुलाया जाए? ("हमने कॉल को ComputeSomething() किया है; यह थ्रेड के अंदर से आ रहा है!") उदाहरण के लिए, यदि ComputeSomethingSlowly() स्पष्ट रूप से या अंतर्निहित कॉल ComputeSomething() । (दूर से ComputeSomethingSlowly() ? और कल्पना करें कि ComputeSomethingSlowly() एक डायलॉग बॉक्स दिखाता है, और DispatchMessage() माध्यम से संदेश लूप DispatchMessage() एक घटना हैंडलर को कॉल करता है, और यह हैंडलर खुद ComputeSomething() का उपयोग करता है
इस मामले में, कॉलिंग स्ट्रीम पहले से ही महत्वपूर्ण अनुभाग का मालिक होगा, बिना किसी कठिनाइयों के अंदर जाएगा, और असंगठित मूल्य को पकड़ लेगा।

इसलिए, जब आप रनटाइम पर एक स्थिर स्थानीय चर का आरंभ देखते हैं, तो सावधान रहें।

लॉकलेस सिंक्रनाइज़ेशन

InterlockedXxx संचालन - 32-बिट मूल्यों और पॉइंटर्स पर परमाणु संचालन का कुशल कार्यान्वयन। लेकिन परमाणु अकेले धागे-सुरक्षा की गारंटी नहीं देता है।

मान लीजिए कि आपके पास एक महत्वपूर्ण खंड द्वारा संरक्षित एक साझा चर है, और कहीं और किसी अन्य फ़ंक्शन में आप इस चर को एक से बढ़ाना चाहते हैं। "महान, मैं एक महत्वपूर्ण अनुभाग के बिना कर सकते हैं, और बस InterlockedIncrement कहते हैं।"

लेकिन कुछ भी नहीं है कि महत्वपूर्ण खंड का उद्देश्य यह सुनिश्चित करना है कि संरक्षित कोड को निष्पादित करते समय कोई भी चर का मूल्य नहीं बदलता है? आपने इसे लिया और "चुपचाप" इसे बदल दिया।

एक और गलतफहमी एक महत्वपूर्ण खंड का उपयोग करके जटिल परमाणु संचालन का कार्यान्वयन है। उदाहरण के लिए, यह है कि वे InterlockedMultiply को कैसे लागू करने की कोशिश करते हैं:

// !
LONG InterlockedMultiply(volatile LONG *plMultiplicand, LONG lMultiplier)
{
EnterCriticalSection(&SomeCriticalSection);
LONG lResult = *plMultiplicand *= lMultiplier;
LeaveCriticalSection(&SomeCriticalSection);
return lResult;
}

हां, यह कोड दो InterlockedMultiply कॉल के बीच संघर्ष को रोकता है, लेकिन एक चर पर अन्य संचालन के संबंध में परमाणुता की गारंटी नहीं देता है। इस उदाहरण को लें:

int x = 2;
Thread1()
{
InterlockedIncrement(&x);
}

Thread2()
{
InterlockedMultiply(&x, 5);
}

यदि गुणा परमाणु है, तो दो ऑपरेशनों का परिणाम x = 15 या x = 11 हो सकता है, जिसके आधार पर ऑपरेशन पहले पूरा किया जा सकता है। लेकिन हमारे "परमाणु" गुणन हमें अन्य मूल्यों को प्राप्त करने की अनुमति देता है, काफी अप्रत्याशित:

स्ट्रीम 1	स्ट्रीम 2
स्रोत: `x` = २
	`InterlockedMultiply(&x, 5)`
	`EnterCriticalSection`
	`x` पढ़ें (पढ़ें: 2)
`InterlockedIncrement(&x);` अब `x` = 3
	5 से गुणा करें (परिणाम: 10)
	लिखना `x` (रिकॉर्ड किया गया: 10)
	`LeaveCriticalSection`
परिणाम: `x` = 10

इतना परमाणु नहीं! इसे कैसे ठीक करें?

यदि ऑपरेशन किया जा रहा है, वैश्विक डेटा से स्वतंत्र एक "शुद्ध कार्य" है, तो इसके परमाणु कार्यान्वयन के लिए InterlockedCompareExchange का उपयोग किया जा सकता है:

LONG InterlockedMultiply(volatile LONG *plMultiplicand, LONG lMultiplier)
{
LONG lOriginal, lResult;
do {
lOriginal = *plMultiplicand;
lResult = lOriginal * lMultiplier;
} while (InterlockedCompareExchange(plMultiplicand,
lResult, lOriginal) != lOriginal);
return lResult;
}

ऑपरेशन में तीन चरण होते हैं।

पहला पैरामीटर मानों का "कैप्चर" है: lOriginal = *plMultiplicand;

दूसरा पकड़े गए मूल्यों पर कार्रवाई है: lResult = lOriginal * lMultiplier;

तीसरा केवल परिणाम को बचाने के लिए है यदि पैरामीटर मान नहीं बदले हैं: InterlockedCompareExchange(plMultiplicand, lResult, lOriginal)

यदि वे बदल गए हैं, तो इसका मतलब है कि हमारा ऑपरेशन किसी अन्य से आगे निकल गया था; और इसलिए, हमारे ऑपरेशन को दोहराया जाना चाहिए।

ऊपर दिए गए उदाहरण पर लौटते हुए: InterlockedIncrement पर एक आक्रमण कॉल के बाद InterlockedIncrement ऑपरेशन ध्यान देगा कि x का मान बदल गया है, और फिर से गुणा करने का प्रयास करेगा। InterlockedCompareExchange में तुलना की परमाणुता सुनिश्चित करती है कि परिणाम केवल तभी दर्ज किए जाएंगे जब पैरामीटर नहीं बदले गए हों।

इस तथ्य पर ध्यान न दें कि ऑपरेशन को किसी अन्य डेटा का उपयोग नहीं करना चाहिए! InterlockedCompareExchange सत्यापित करने InterlockedCompareExchange असमर्थ है कि ऑपरेशन द्वारा उपयोग किए जाने वाले वैश्विक चर परिवर्तित नहीं हुए हैं। अन्यथा, "एबीए समस्या" नामक एक स्थिति संभव है: ऑपरेशन के पहले निष्पादन के दौरान, पैरामीटर मान ए था; फिर, बहते धागे से किसी का ध्यान नहीं गया, तो उसका मान B में बदल गया, और फिर A. InterlockedCompareExchange ध्यान नहीं जाएगा कि कुछ बदल गया है, और पहली बार गणना की गई मान को बचाएगा। यदि परिणाम को प्रभावित करने वाले अन्य डेटा पैरामीटर के साथ बदल गए हैं, तो रिकॉर्ड किया गया परिणाम गलत होगा।

यदि परमाणु के रूप में एक सामान्य चर पर सभी कार्यों को लागू करना संभव है, तो इसे महत्वपूर्ण अनुभाग द्वारा संरक्षित करने की आवश्यकता नहीं होगी; प्रदर्शन, और मापनीयता, और सिस्टम संसाधनों की खपत में दोनों हासिल किए जाते हैं। बहु-थ्रेडेड प्रोग्राम को डिज़ाइन करने के इस दृष्टिकोण को "लॉकलेस सिंक्रोनाइज़ेशन" कहा जाता है। इसका लाभ मुख्य रूप से इस तथ्य में निहित है कि यदि कोई थ्रेड लॉक (महत्वपूर्ण खंड, म्यूटेक्स, सेमाफोर, आदि) को पकड़ता है और फिर, एक कारण या किसी अन्य के लिए, "अटक जाता है", तो सभी एक ही लॉक का उपयोग करके बहते हैं, " फंस जाओ ”उसके बाद। लॉकलेस सिंक्रोनाइज़ेशन के साथ, एक भी "अटका हुआ" धागा पूरे सिस्टम को स्टाल नहीं कर सकता है: चाहे कितने भी थ्रेड्स "अटके" हों, कम से कम एक में काम करना जारी रहेगा। लॉकलेस सिंक्रोनाइज़ेशन रियल-टाइम सिस्टम में मांग में है, जहां कार्य निष्पादन समय ऑपरेटिंग सिस्टम द्वारा प्रत्येक थ्रेड के लिए प्रोसेसर समय के आवंटन के vicissitudes पर निर्भर नहीं होना चाहिए।

लॉकलेस थ्रेड-सुरक्षित आलसी आरंभीकरण

मान लीजिए कि हम एक-दूसरे को चंचल करने के लिए आलसी होने का फैसला करते हैं। एकल-थ्रेडेड प्रोग्राम में, यह सीधा है:

// a b : a ≥ 0 b ≥ a.
// -1 ,
// " "
int a = -1, b = -1;

void LazyInitialize()
{
if (a != -1) return; //

a = calculate_nominal_a();
b = calculate_nominal_b();

//
a = max(0, a);
b = max(a, b);
}

जैसा कि ऊपर दिए गए उदाहरणों में, एक बहु-थ्रेडेड प्रोग्राम में, इस तरह के इनिशियलाइज़ेशन से उड़ान की स्थिति बन सकती है:

स्ट्रीम 1	स्ट्रीम 2
`if (a != -1)` [निष्पादित नहीं]
`a = calculate_nominal_a();` // रिटर्न 2
	`if (a != -1) return;` // बहुत जल्दी!

पहले धागे ने b गणना करने से पहले निष्पादन को बाधित किया था, इसलिए दूसरा धागा इसके असमान मूल्य को ले जाएगा।

“आह, यह ठीक करना आसान है! यह जाँचने के लिए कि क्या आरंभीकरण पूरा हो गया है, हम जाँचेंगे कि नहीं, लेकिन b । "

void LazyInitialize()
{
if ( b != -1) return; //

a = calculate_nominal_a();
b = calculate_nominal_b();

//
a = max(0, a);
b = max(a, b);
}

एयर कंडीशनिंग अभी भी संभव है:

स्ट्रीम 1	स्ट्रीम 2
`if (b != -1)` [निष्पादित नहीं हुआ]
`a = calculate_nominal_a();` // रिटर्न 2
`b = calculate_nominal_b();` // 1 रिटर्न
	`if (b != -1) return;` // बहुत जल्दी!

दूसरा धागा मानों को a और b लेगा जो लगाए गए प्रतिबंधों को पूरा नहीं करते हैं।

“आप खुद को इससे बचा सकते हैं! मैं स्थानीय चरों में a और b के मूल्यों की गणना करूंगा, और गणना पूर्ण होने पर ही उन्हें वैश्विक रूप से लिखूंगा, ताकि दूसरा धागा "अर्ध-समाप्त" मानों को देखने में सक्षम न हो।

void LazyInitialize()
{
if (b != -1) return; //

//
int temp_a = calculate_nominal_a();
int temp_b = calculate_nominal_b();

//
temp_a = max(0, temp_a );
temp_b = max( temp_a, temp_b );

//
a = temp_a;
b = temp_b;
}

लगभग सही; लेकिन उड़ान कंडीशनिंग अभी भी संभव है:

स्ट्रीम 1	स्ट्रीम 2
`if (b != -1)` [निष्पादित नहीं हुआ]
`temp_a = calculate_nominal_a();` // रिटर्न 2
`temp_b = calculate_nominal_b();` // 1 रिटर्न
`temp_a = max(0, temp_a);` // temp_a = 2
`temp_b = max(temp_a, temp_b);` // temp_b = 2
`a = temp_a;` // प्रोसेसर कैश को लिखा गया है
`b = temp_b;` // प्रोसेसर कैश को लिखा गया है
`b` मान को मेमोरी में संग्रहीत किया जाता है
	`if (b != -1) return;` // बहुत जल्दी!
का मान स्मृति में संग्रहीत किया जाता है

कंपाइलर गारंटी नहीं देता है कि b का नया मूल्य अन्य प्रोसेसर से पहले के नए मूल्य से उपलब्ध होगा। यद्यपि प्रोसेसर इस क्रम में असाइनमेंट करता है, एक मल्टीप्रोसेसर सिस्टम में साझा मेमोरी कंट्रोल सर्किट को उन्हें रिवर्स ऑर्डर में लिखने का अधिकार है, ताकि अन्य प्रोसेसर a = -1 और b = 2 देखें।

मेमोरी के लिए b लिखना एक रिलीज ऑपरेशन के रूप में किया जाना चाहिए; इसके बाद पिछले सभी ऑपरेशनों को मेमोरी में परिलक्षित होने के लिए मजबूर किया जाता है, इससे पहले कि अन्य प्रोसेसर नया मूल्य देखें।

void LazyInitialize()
{
if (b != -1) return; //

//
int temp_a = calculate_nominal_a();
int temp_b = calculate_nominal_b();

//
temp_a = max(0, temp_a);
temp_b = max(temp_a, temp_b);

//
a = temp_a;
// b
// , ,
// Release
InterlockedCompareExchangeRelease(
reinterpret_cast<LONG*>&b, temp_b, -1);
}

परिणामी कोड एक बिना चाबी वाले परमाणु ऑपरेशन के समान है, केवल इनपुट मापदंडों के बिना: सबसे पहले, सभी गणना स्थानीय चर में की जाती हैं, और फिर उन्हें एक एकल InterlockedCompareExchangeRelease किए गए InterlockedCompareExchangeRelease ऑपरेशन के साथ मेमोरी में लिखा जाता है। यह मानकर कि calculate_nominal_a() और calculate_nominal_b() हमेशा समान मान लौटाते हैं, हमें फिर से ऑपरेशन करने की आवश्यकता नहीं है यदि यह विफल हो जाता है: यदि चर हमारे द्वारा आरंभीकृत नहीं किए गए थे, तो एक और धागा ने हमारे लिए अपना काम किया। (ध्यान दें: यदि InterlockedCompareExchangeRelease विफल रहता है, तो चर अभी भी हमारी स्ट्रीम द्वारा अधिलेखित हो जाएगा!)

अंत में, रेमंड ने एक पहेली का सुझाव दिया: क्या यह परिवर्तनशील temp_a बिना करना संभव है? वास्तव में, किसी भी मामले में, थ्रेड के उपयोग के बाद ही मूल्य सुनिश्चित किया जाता है कि आरंभीकरण पूरा हो गया है।

सी ++ में सुरक्षित आलसी प्रारंभिक सूत्र

C ++ बिल्ट-इन के साथ आलसी इनिशियलाइज़ेशन

लॉकलेस सिंक्रनाइज़ेशन

लॉकलेस थ्रेड-सुरक्षित आलसी आरंभीकरण

More articles: