👍 🍡 🧡 बहु-थ्रेडेड अनुप्रयोग में सिंगलटन कार्यान्वयन 🤙🏻 🔃 🔂

परिचय

फिलहाल, एक थ्रेड पर चल रहे सॉफ़्टवेयर की कल्पना करना कठिन है। बेशक, कई सरल कार्य हैं जिनके लिए एक धागा पर्याप्त से अधिक है। हालांकि, यह हमेशा से दूर है और मध्यम या उच्च जटिलता के अधिकांश कार्य एक या दूसरे तरीके से मल्टीथ्रेडिंग का उपयोग करते हैं। इस लेख में, मैं एक बहु-थ्रेडेड वातावरण में सिंगलटन का उपयोग करने के बारे में बात करूंगा। स्पष्ट सादगी के बावजूद, इस विषय में कई बारीकियों और दिलचस्प प्रश्न हैं, इसलिए मुझे लगता है कि यह एक अलग लेख के योग्य है। यह इस बात पर चर्चा नहीं करेगा कि सिंगलनेट का उपयोग क्यों किया जाए, साथ ही उनका सही उपयोग कैसे किया जाए। इन मुद्दों को स्पष्ट करने के लिए, मैं सिंगलटन [1] , [2] , [3] से संबंधित विभिन्न मुद्दों पर अपने पिछले लेखों का संदर्भ देने की सलाह देता हूं। यह आलेख एकल के कार्यान्वयन पर मल्टीथ्रेडिंग के प्रभाव पर चर्चा करेगा और विकास के दौरान आने वाले मुद्दों पर चर्चा करेगा।

समस्या का बयान

पिछले लेखों में, निम्नलिखित सिंगलटन कार्यान्वयन पर विचार किया गया था:

template<typename T> T& single() { static T t; return t; }

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

सी ++ मानक

व्यावहारिक दृष्टिकोण से इस प्रश्न का उत्तर देने से पहले, मेरा सुझाव है कि आप अपने आप को सैद्धांतिक पहलू से परिचित करें, अर्थात। C ++ मानक से परिचित हों। वर्तमान में, कंपाइलर 2 मानकों का समर्थन करते हैं: 2003 और 2011।

$ 6.7.4, सी ++ 03

स्थिर भंडारण अवधि (3.7.1) के साथ सभी स्थानीय वस्तुओं का शून्य-आरंभीकरण (8.5) किसी अन्य आरंभीकरण से पहले किया जाता है। स्थैतिक भंडारण अवधि के साथ POD प्रकार (3.9) की एक स्थानीय वस्तु स्थिर-अभिव्यक्ति के साथ आरंभीकृत होती है, जब इसका ब्लॉक पहले दर्ज किया जाता है। एक कार्यान्वयन को अन्य स्थानीय वस्तुओं के स्थैतिक भंडारण अवधि के साथ प्रारंभिक आरंभीकरण करने की अनुमति है उन्हीं शर्तों के तहत जिन्हें कार्यान्वयन की अनुमति दी गई है कि वे किसी वस्तु को स्थैतिक भंडारण अवधि के साथ नामस्थान स्कोप (3.6.2) में स्थिर कर सकें। अन्यथा ऐसी वस्तु को इनिशियलाइज़ किया जाता है जब पहली बार नियंत्रण उसकी घोषणा से गुजरता है; इस तरह की वस्तु को इसके आरंभ के पूरा होने पर आरंभिक माना जाता है। यदि अपवाद को फेंकने से आरंभीकरण बाहर निकलता है, तो इनिशियलाइज़ेशन पूरा नहीं होता है, इसलिए यह फिर से कोशिश की जाएगी कि अगली बार नियंत्रण घोषणा में प्रवेश कर जाए। यदि नियंत्रण घोषणा (पुनरावर्ती) में फिर से प्रवेश करता है जबकि ऑब्जेक्ट को आरंभीकृत किया जा रहा है, तो व्यवहार अपरिभाषित है।

$ 6.7.4, सी ++ 11

स्थिर संग्रहण अवधि (3.7.1) या थ्रेड स्टोरेज अवधि (3.7.2) के साथ सभी ब्लॉक-स्कोप वैरिएबल का शून्य-आरंभीकरण (8.5) किसी अन्य इनिशियलाइज़ेशन के होने से पहले किया जाता है। स्थैतिक भंडारण अवधि के साथ एक ब्लॉक-स्कोप इकाई की निरंतर आरंभीकरण (3.6.2), यदि लागू हो, तो इसके ब्लॉक को पहले दर्ज करने से पहले किया जाता है। कार्यान्वयन को स्थिर या थ्रेड स्टोरेज अवधि के साथ अन्य ब्लॉक-स्कोप वैरिएबल्स के प्रारंभिक आरंभीकरण को उन्हीं शर्तों के तहत करने की अनुमति है, जो कि कार्यान्वयन को वैचारिक रूप से वैरिएबल या थ्रेड स्टोरेज अवधि के साथ नामस्थान स्कोप (3.6.2) में वैरिएबल इनिशियलाइज़ करने की अनुमति है। अन्यथा ऐसा वैरिएबल इनिशियलाइज़ हो जाता है जब पहली बार नियंत्रण अपनी घोषणा से गुजरता है; इस तरह के एक चर को इसके आरंभ के पूरा होने पर प्रारंभिक माना जाता है। यदि अपवाद को फेंकने से आरंभीकरण बाहर निकलता है, तो इनिशियलाइज़ेशन पूरा नहीं होता है, इसलिए यह फिर से कोशिश की जाएगी कि अगली बार नियंत्रण घोषणा में प्रवेश कर जाए। यदि चर को प्रारंभ किया जा रहा है, तो नियंत्रण घोषणा में समवर्ती रूप से प्रवेश करता है, समवर्ती निष्पादन प्रारंभ (*) के पूरा होने की प्रतीक्षा करेगा । यदि नियंत्रण पुनः घोषणा में पुन: प्रवेश करता है जबकि चर को आरंभ किया जा रहा है, तो व्यवहार अपरिभाषित है।

(*) कार्यान्वयन को इनिशियलाइज़र के निष्पादन के आसपास किसी भी गतिरोध का परिचय नहीं देना चाहिए

( मेरे द्वारा हाइलाइट किया गया )

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

अब यह पता लगाना बाकी है कि कौन से संकलक वास्तव में नए मानक का समर्थन करते हैं, और जो केवल यह दिखावा करने की कोशिश करते हैं कि वे समर्थन करते हैं। ऐसा करने के लिए, हम निम्नलिखित प्रयोग करेंगे।

प्रयोग

मल्टी-थ्रेडेड प्रिमिटिव्स का उपयोग करते समय, मैं अल्टीमेट ++ फ्रेमवर्क का उपयोग करूंगा। यह काफी हल्का और उपयोग में आसान है। इस लेख के ढांचे में, यह एक मौलिक भूमिका नहीं निभाता है (उदाहरण के लिए, आप बूस्ट का उपयोग कर सकते हैं)।

हमारे प्रयोग के लिए, हम एक ऐसा वर्ग लिखेंगे जो बनाने में काफी समय लगता है:

 struct A { A() { Cout() << '{'; //     Thread::Sleep(10); //  10  if (++ x != 1) Cout() << '2'; //  :    Cout() << '}'; //    } ~A() { Cout() << '~'; //   } int x; };

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

अगला, हम एक नया सूत्र बनाते समय एक फ़ंक्शन लिखते हैं:

 void threadFunction(int i) { Cout() << char('a'+i); //   -    ,    A& a = single<A>(); //    if (ax == 0) Cout() << '0'; //  :    Cout() << char('A'+i); //   -    }

और हम थ्रेडफंक्शन फ़ंक्शन को 5 थ्रेड्स से एक साथ कॉल करेंगे, जिससे उस स्थिति का अनुकरण किया जाएगा जब सिंगलटन के लिए एक प्रतियोगी पहुंच हो:

 for (int i = 0; i < 5; ++ i) Thread::Start(callback1(threadFunction, i)); Thread::ShutdownThreads();

प्रयोग के लिए, मैंने 2 संकलक चुने जो आज काफी लोकप्रिय हैं: MSVC 2010 और GCC 4.5। MSVC 2012 कंपाइलर का उपयोग करके परीक्षण भी किया गया था, परिणाम पूरी तरह से 2010 संस्करण के अनुरूप है, इसलिए मैं भविष्य में इसके उल्लेख को छोड़ दूंगा।

GCC के लिए स्टार्टअप परिणाम:

ab {cde} ABCDE ~

MSVC के लिए स्टार्टअप परिणाम:

ab {0cB0dCe00DE} A ~

प्रयोगात्मक परिणामों की चर्चा

हम परिणामों पर चर्चा करते हैं। जीसीसी के लिए , निम्नलिखित होता है:

थ्रेड 1 के लिए थ्रेडफ़ंक्शन प्रारंभ करें
धागा 2 के लिए थ्रेडफंक्शन शुरू करें
सिंगलटन इनिशियलाइज़ेशन शुरू
धागा 3 के लिए थ्रेडफंक्शन शुरू करें
धागा 4 के लिए थ्रेडफंक्शन शुरू करें
धागा 5 के लिए थ्रेडफंक्शन शुरू करें
सिंगलटन आरंभीकरण पूरा
सभी थ्रेड 1-5 के लिए क्रमिक रूप से बाहर निकलें
कार्यक्रम समाप्ति और सिंगलटन विनाश

यहां कोई आश्चर्य की बात नहीं है: सिंगलटन को केवल एक बार आरंभीकृत किया जाता है और थ्रेडफंक्शन फ़ंक्शन केवल सिंगलटन के आरंभीकरण के बाद अपना काम पूरा करता है => जीसीसी एक बहु-थ्रेडेड वातावरण में ऑब्जेक्ट को सही ढंग से प्रारंभ करता है।

MSVC के साथ स्थिति कुछ अलग है:

थ्रेड 1 के लिए थ्रेडफ़ंक्शन प्रारंभ करें
धागा 2 के लिए थ्रेडफंक्शन शुरू करें
सिंगलटन इनिशियलाइज़ेशन शुरू
त्रुटि: सिंगलटन आरंभिक नहीं है
धागा 3 के लिए थ्रेडफंक्शन शुरू करें
धागा 2 के लिए बाहर निकलने का धागा
त्रुटि: सिंगलटन आरंभिक नहीं है
...
5 धागे के लिए बाहर निकलें
सिंगलटन आरंभीकरण पूरा
धागा 1 के लिए बाहर निकलने का धागा
कार्यक्रम समाप्ति और सिंगलटन विनाश

इस मामले में, पहली स्ट्रीम के लिए कंपाइलर सिंगलटन को इनिशियलाइज़ करने के लिए शुरू होता है, और बाकी के लिए - यह तुरंत एक ऐसी वस्तु लौटाता है जिसे इनिशियलाइज़ करने का समय भी नहीं मिला। इसलिए, बहु-थ्रेडेड वातावरण में MSVC ठीक से काम नहीं करता है।

प्रयोगात्मक परिणामों का विश्लेषण

आइए यह पता लगाने की कोशिश करें कि माना गया संकलक द्वारा प्राप्त परिणाम कैसे भिन्न होता है। ऐसा करने के लिए, कोड को संकलित और अलग करें:

जीसीसी :

 5 T& single() 0x00418ad8 <+0>: push %ebp 0x00418ad9 <+1>: mov %esp,%ebp 0x00418adb <+3>: sub $0x28,%esp 6 { 7 static T t; 0x00418ade <+6>: cmpb $0x0,0x48e070 0x00418ae5 <+13>: je 0x418af0 <single<A>()+24> 0x00418ae7 <+15>: mov $0x49b780,%eax 0x00418aec <+20>: leave 0x00418aed <+21>: ret 0x00418af0 <+24>: movl $0x48e070,(%esp) 0x00418af7 <+31>: call 0x485470 <__cxa_guard_acquire> 0x00418afc <+36>: test %eax,%eax 0x00418afe <+38>: je 0x418ae7 <single<A>()+15> 0x00418b00 <+40>: movl $0x49b780,(%esp) 0x00418b07 <+47>: call 0x4195d8 <A::A()> 0x00418b0c <+52>: movl $0x48e070,(%esp) 0x00418b13 <+59>: call 0x4855cc <__cxa_guard_release> 0x00418b18 <+64>: movl $0x485f04,(%esp) 0x00418b1f <+71>: call 0x401000 <atexit> 8 return t; 9 } 0x00418b24 <+76>: mov $0x49b780,%eax 0x00418b29 <+81>: leave 0x00418b2a <+82>: ret

यह देखा जाता है कि ऑब्जेक्ट ए के कंस्ट्रक्टर को कॉल करने से पहले, कंपाइलर सिंक्रोनाइज़ेशन फ़ंक्शंस के लिए एक कॉल सम्मिलित करता है: __cxa_guard_acquire / __ cxa_guard_release, जो आपको एकल फ़ंक्शन को उसी समय सुरक्षित रूप से चलाने की अनुमति देता है जब सिंगलटन को इनिशियलाइज़ कर रहा हो।

MSVC :

 T& single() { 00E51420 mov eax,dword ptr fs:[00000000h] 00E51426 push 0FFFFFFFFh 00E51428 push offset __ehhandler$??$single@UA@@@@YAAAUA@@XZ (0EE128Eh) 00E5142D push eax static T t; 00E5142E mov eax,1 00E51433 mov dword ptr fs:[0],esp ;   00E5143A test byte ptr [`single<A>'::`2'::`local static guard' (0F23944h)],al 00E51440 jne single<A>+47h (0E51467h) ;     "" 00E51442 or dword ptr [`single<A>'::`2'::`local static guard' (0F23944h)],eax 00E51448 mov ecx,offset t (0F23940h) 00E5144D mov dword ptr [esp+8],0 ;  :   00E51455 call A::A (0E51055h) 00E5145A push offset `single<A>'::`2'::`dynamic atexit destructor for 't'' (0EED390h) 00E5145F call atexit (0EA0AD1h) 00E51464 add esp,4 return t; } 00E51467 mov ecx,dword ptr [esp] 00E5146A mov eax,offset t (0F23940h) 00E5146F mov dword ptr fs:[0],ecx 00E51476 add esp,0Ch 00E51479 ret

यहां, कंपाइलर वेरिएशन को वेरिफाई करने के लिए 0x0F23944 पर वेरिएबल का इस्तेमाल करता है। यदि ऑब्जेक्ट को अभी तक प्रारंभ नहीं किया गया है, तो यह मान एक पर सेट है, और फिर सिंगलटन के आरंभीकरण को बिना किसी लागत के कहा जाता है। यह देखा जा सकता है कि कोई सिंक्रनाइज़ेशन प्रदान नहीं किया गया है, जो हमारे प्रयोग के परिणामस्वरूप प्राप्त परिणाम की व्याख्या करता है।

सरल उपाय

आप एक काफी सरल समाधान का उपयोग कर सकते हैं जो हमारी समस्या को हल करता है। ऐसा करने के लिए, ऑब्जेक्ट बनाने से पहले, हम ऑब्जेक्ट तक पहुंच को सिंक्रनाइज़ करने के लिए म्यूटेक्स का उपयोग करेंगे:

 //        struct StaticLock : Mutex::Lock { StaticLock() : Mutex::Lock(mutex) { Cout() << '+'; } ~StaticLock() { Cout() << '-'; } private: static Mutex mutex; }; Mutex StaticLock::mutex; template<typename T> T& single() { StaticLock lock; //   mutex.lock() static T t; //   return t; //  mutex.unlock()    }

स्टार्टअप परिणाम:

ab + {cde} -A + -B + -C + -D + -E ~

संचालन का क्रम:

थ्रेड 1 के लिए थ्रेडफ़ंक्शन प्रारंभ करें
धागा 2 के लिए थ्रेडफंक्शन शुरू करें
वैश्विक ताला लेना: mutex.lock ()
सिंगलटन इनिशियलाइज़ेशन शुरू
धागा 3 के लिए थ्रेडफंक्शन शुरू करें
धागा 4 के लिए थ्रेडफंक्शन शुरू करें
धागा 5 के लिए थ्रेडफंक्शन शुरू करें
सिंगलटन आरंभीकरण पूरा
वैश्विक लॉक रिलीज़: mutex.unlock ()
धागा 1 के लिए बाहर निकलने का धागा
वैश्विक ताला लेना: mutex.lock ()
वैश्विक लॉक रिलीज़: mutex.unlock ()
धागा 2 के लिए बाहर निकलने का धागा
...
5 धागे के लिए बाहर निकलें
कार्यक्रम समाप्ति और सिंगलटन विनाश

ऐसा कार्यान्वयन पूरी तरह से एक असंगठित वस्तु को वापस करने की समस्या को समाप्त करता है: mutex.lock () को आरंभीकरण से पहले कहा जाता है, और mutex.unlock () आरंभीकरण पूरा होने के बाद कहा जाता है। शेष धागे उपयोग करने से पहले प्रारंभ होने की प्रतीक्षा करते हैं। हालांकि, इस दृष्टिकोण में एक महत्वपूर्ण माइनस है: लॉकिंग का उपयोग हमेशा किया जाता है, भले ही ऑब्जेक्ट पहले से ही प्रारंभ हो या नहीं। प्रदर्शन में सुधार करने के लिए, मैं सिंक्रनाइज़ेशन को केवल उस समय उपयोग करना चाहता हूं जब हम किसी ऐसी वस्तु तक पहुंचना चाहते हैं जिसे अभी तक आरंभ नहीं किया गया है (जैसा कि जीसीसी के लिए लागू किया गया है )।

डबल-चेकिंग लॉकिंग पैटर्न

उपरोक्त विचार को लागू करने के लिए, अक्सर एक दृष्टिकोण जिसे डबल-चेक लॉकिंग पैटर्न ( DCLP ) कहा जाता है या डबल-चेक लॉक डिज़ाइन पैटर्न अक्सर उपयोग किया जाता है। इसका सार क्रियाओं के निम्नलिखित सेट द्वारा वर्णित है:

हालत की जाँच: आरंभीकृत या नहीं? यदि हाँ, तो तुरंत वस्तु का लिंक वापस करें
ताला लगा लो
हम दूसरी बार स्थिति की जांच करते हैं, यदि इसे आरंभीकृत किया जाता है, तो हम लॉक को हटा देते हैं और लिंक वापस करते हैं
सिंगलटन को इनिशियलाइज़ करें
स्थिति को "आरंभीकृत" में बदलें
लॉक निकालें और लिंक वापस करें

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

DCLP को निम्न उदाहरण द्वारा चित्रित किया जा सकता है:

 template<typename T> T& single() { static T* pt; if (pt == 0) //  ,   { StaticLock lock; if (pt == 0) //  ,   pt = new T; } return *pt; }

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

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

दूसरी अधिक गंभीर समस्या निम्नलिखित पंक्ति है:

 pt = new T;

आइए इस पर अधिक विस्तार से विचार करें। इस पंक्ति को इस प्रकार फिर से लिखा जा सकता है (मैं संक्षिप्तता से निपटने के अपवाद को छोड़ दूँगा):

 pt = operator new(sizeof(T)); //     new (pt) T; // placement new:

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

अब ऊपर वर्णित दोनों समस्याओं को ठीक करने का प्रयास करते हैं।

प्रस्तावित दृष्टिकोण

हम एक सिंगलटन बनाने के लिए दो कार्यों का परिचय देते हैं: हम एक का उपयोग करेंगे जैसे कि हमारे पास एक एकल-थ्रेडेड अनुप्रयोग है, और दूसरा बहु-थ्रेडेड उपयोग के लिए:

 //      template<typename T> T& singleUnsafe() { static T t; return t; } //       template<typename T> T& single() { static T* volatile pt; if (pt == 0) { T* tmp; { StaticLock lock; tmp = &singleUnsafe<T>(); } pt = tmp; } return *pt; }

विचार इस प्रकार है। हम जानते हैं कि हमारा प्रारंभिक कार्यान्वयन (अब एकलउपसफे समारोह) एकल-थ्रेडेड अनुप्रयोग में ठीक काम करता है। इसलिए, हम सभी को कॉल की क्रमबद्धता की आवश्यकता होती है, जो तालों के सही उपयोग से प्राप्त होती है। एक अर्थ में, 2 चेक भी हैं, केवल लॉक के बाहर पहला चेक एक पॉइंटर का उपयोग करता है, और दूसरा कंपाइलर द्वारा उत्पन्न आंतरिक चर का उपयोग करता है। यह संकलक द्वारा अति-अनुकूलन की स्थिति में परिचालनों के पुन: संचालन को रोकने के लिए अस्थिर कीवर्ड का भी उपयोग करता है। यह भी ध्यान देने योग्य है कि pt पॉइंटर असाइनमेंट ताले के बाहर होता है। यह कोड निष्पादन के दौरान प्रोसेसर द्वारा संचालन को फिर से रोकने के लिए है।

ऐसे कार्यान्वयन को संकलित करने का परिणाम नीचे दिखाया गया है:

 template<typename T> T& single() { ;   00083B30 push 0FFFFFFFFh 00083B32 push offset __ehhandler$??$single@UA@@@@YAAAUA@@XZ (0A13B6h) 00083B37 mov eax,dword ptr fs:[00000000h] 00083B3D push eax 00083B3E mov dword ptr fs:[0],esp 00083B45 push ecx static T* volatile pt; if (pt == 0) ;     00083B46 mov eax,dword ptr [pt (0E3950h)] 00083B4B test eax,eax 00083B4D jne single<A>+7Dh (83BADh) { T* tmp; { StaticLock lock; ;   EnterCriticalSection    00083B4F push offset staticMutex (0E3954h) 00083B54 mov dword ptr [esp+4],offset staticMutex (0E3954h) 00083B5C call dword ptr [__imp__EnterCriticalSection@4 (0ED6A4h)] tmp = &singleUnsafe<T>(); 00083B62 mov eax,1 00083B67 mov dword ptr [esp+0Ch],0 ;   00083B6F test byte ptr [`singleUnsafe<A>'::`2'::`local static guard' (0E394Ch)],al 00083B75 jne single<A>+68h (83B98h) 00083B77 or dword ptr [`singleUnsafe<A>'::`2'::`local static guard' (0E394Ch)],eax 00083B7D mov ecx,offset t (0E3948h) 00083B82 mov byte ptr [esp+0Ch],al ;  :   00083B86 call A::A (1105Fh) 00083B8B push offset `singleUnsafe<A>'::`2'::`dynamic atexit destructor for 't'' (0AD4D0h) 00083B90 call atexit (60BB1h) 00083B95 add esp,4 } ;   LeaveCriticalSection    00083B98 push offset staticMutex (0E3954h) 00083B9D call dword ptr [__imp__LeaveCriticalSection@4 (0ED6ACh)] pt = tmp; ;    pt    00083BA3 mov dword ptr [pt (0E3950h)],offset t (0E3948h) } return *pt; } 00083BAD mov ecx,dword ptr [esp+4] ;     eax 00083BB1 mov eax,dword ptr [pt (0E3950h)] 00083BB6 mov dword ptr fs:[0],ecx 00083BBD add esp,10h 00083BC0 ret

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

 template<typename T> T& single() { 000000013F401600 push rdi 000000013F401602 sub rsp,30h 000000013F401606 mov qword ptr [rsp+20h],0FFFFFFFFFFFFFFFEh 000000013F40160F mov qword ptr [rsp+48h],rbx static T* volatile pt; if (pt == 0) 000000013F401614 mov rax,qword ptr [pt (13F4F5890h)] 000000013F40161B test rax,rax 000000013F40161E jne single<A>+75h (13F401675h) { T* tmp; { StaticLock lock; 000000013F401620 lea rbx,[staticMutex (13F4F58A0h)] 000000013F401627 mov qword ptr [lock],rbx 000000013F40162C mov rcx,rbx 000000013F40162F call qword ptr [__imp_EnterCriticalSection (13F50CCC0h)] ; nop !!! 000000013F401635 nop tmp = &singleUnsafe<T>(); 000000013F401636 mov eax,dword ptr [`singleUnsafe<A>'::`2'::`local static guard' (13F4F588Ch)] 000000013F40163C lea rdi,[t (13F4F5888h)] 000000013F401643 test al,1 000000013F401645 jne single<A>+65h (13F401665h) 000000013F401647 or eax,1 000000013F40164A mov dword ptr [`singleUnsafe<A>'::`2'::`local static guard' (13F4F588Ch)],eax 000000013F401650 mov rcx,rdi 000000013F401653 call A::A (13F401087h) 000000013F401658 lea rcx,[`singleUnsafe<A>'::`2'::`dynamic atexit destructor for 't'' (13F4A6FF0h)] 000000013F40165F call atexit (13F456664h) ; nop !!! 000000013F401664 nop } 000000013F401665 mov rcx,rbx 000000013F401668 call qword ptr [__imp_LeaveCriticalSection (13F50CCD0h)] pt = tmp; 000000013F40166E mov qword ptr [pt (13F4F5890h)],rdi } return *pt; 000000013F401675 mov rax,qword ptr [pt (13F4F5890h)] } 000000013F40167C mov rbx,qword ptr [rsp+48h] 000000013F401681 add rsp,30h 000000013F401685 pop rdi 000000013F401686 ret

मैंने विशेष रूप से एनओपी निर्देशों का उल्लेख किया है। उन्हें उत्पन्न अपवाद की स्थिति में स्टैक पदोन्नति के लिए मार्कर के रूप में उपयोग किया जाता है। इस दृष्टिकोण में उत्पन्न अपवाद के अभाव में कोड निष्पादन के लिए कोई ओवरहेड भी नहीं है।

निष्कर्ष

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

पुनश्च

यह लेख बहुस्तरीय मुद्दों का परिचय है। यह एक सिंगलटन ऑब्जेक्ट बनाते समय पहुंच की समस्या को हल करता है। उनके डेटा के आगे उपयोग के साथ, अन्य गंभीर प्रश्न उठते हैं, जिनके बारे में अगले लेख में विस्तार से चर्चा की जाएगी।

अद्यतन

सिंगलटन कार्यान्वयन को लेख में टिप्पणियों को ध्यान में रखते हुए तय किया गया है।

साहित्य

[१] हैब्रह्ब: सिंगलटन पैटर्न का उपयोग करना
[२] हैब्रह्ब: सिंगलटन और ऑब्जेक्ट लाइफटाइम
[३] हब्राह्र: निर्भरता का उलटा और डिजाइन पैटर्न उत्पन्न करना
[४] सी ++ ० एक्स मानक की अंतिम समिति ड्राफ्ट (एफसीडी)
[५] सी ++ मानक - एएनएसआई आईएसओ आईईसी
१४ 6 I२ २००३ [६] अंतिम ++: सी ++ क्रॉस-प्लेटफॉर्म रैपिड एप्लिकेशन डेवलपमेंट फ्रेमवर्क
[Bo] बूस्ट सी ++ लाइब्रेरी
[]] विकिपीडिया : डबल-चेकिंग लॉकिंग
[9] एंटीपैटर्न डबल-चेक लॉकिंग से मिलो

बहु-थ्रेडेड अनुप्रयोग में सिंगलटन कार्यान्वयन