इस लेख में, मैं लॉक-मुक्त कंटेनरों को लिखने के लिए तकनीकों के साथ हेब्रोसोसिटी को जारी रखूंगा, विज्ञापन के माध्यम से (उम्मीद है कि बहुत दखलंदाजी से नहीं) मेरे libcds पुस्तकालय।

हम ताला-मुक्त कंटेनरों के लिए सुरक्षित मेमोरी रिलीज़ के लिए एक और तकनीक के बारे में बात करेंगे - RCU। यह तकनीक पहले से चर्चा की गई ला हाजार्ड पॉइंटर एल्गोरिदम से काफी अलग है।

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

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


RCU तकनीक के निर्माता और सक्रिय प्रवर्तक पॉल मैककेनी हैं। वह "RCU प्रेमियों" का एक पूरा स्कूल जाता है, जहाँ से लॉक-फ़्री और गैर-पारंपरिक सिंक्रोनाइज़ेशन योजनाओं के क्षेत्र में कई जाने-माने वैज्ञानिक उभरे, और वह लिनक्स कर्नेल (लिनक्स-कर्नेल RCU) और RCU पर कई कार्यों के लेखक "RCU मास्टर" भी हैं। ।


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

आरसीयू का सामान्य विवरण

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

RCU तकनीक में पाठक रीड-साइड क्रिटिकल सेक्शन में चलते हैं। ऐसे महत्वपूर्ण खंड में प्रवेश करते समय, रीडर rcu_read_lock() फ़ंक्शन को कॉल करता है, और बाहर निकलने पर, rcu_read_unlock() । ये बहुत ही हल्के विशेषताएं हैं जिनका प्रदर्शन पर लगभग कोई प्रभाव नहीं है; लिनक्स कर्नेल में वे सब कुछ (शून्य-ओवरहेड) का वजन नहीं करते हैं।
यदि स्ट्रीम क्रिटिकल रीडिंग सेक्शन में नहीं है, तो यह कहा जाता है कि स्ट्रीम क्विज़ेंट स्टेट (quiescent state, quiescent state) में है। किसी भी समय की अवधि जिसमें प्रत्येक धागा कम से कम एक बार एक मौन अवस्था में एक अनुग्रह अवधि कहलाता है। प्रत्येक महत्वपूर्ण रीडिंग सेक्शन जो ग्रेस पीरियड से पहले शुरू होता है, ग्रेस पीरियड समाप्त होने से पहले समाप्त होना चाहिए। प्रत्येक ग्रेस पीरियड को परिमित होने की गारंटी दी जाती है, क्योंकि कोई भी महत्वपूर्ण रीडिंग सेक्शन परिमित होता है (यह समझा जाता है कि थ्रेड्स की संख्या परिमित है, और यह भी कि हम अच्छे प्रोग्रामर हैं और अंतहीन लूप से बचते हैं, साथ ही थ्रेड क्रैश भी होते हैं)।


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

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

उपयोगकर्ता-अंतरिक्ष RCU

यह निर्णय 2009 में पी। मैकनेनी के प्रतिनिधि एम। डेसनॉयर्स ने अपने शोध प्रबंध में दिया था , जिसका अध्याय 6 कहा जाता है: आरसीयू का उपयोगकर्ता-स्तर कार्यान्वयन।
M.Desnoyers उपयोगकर्ता-अंतरिक्ष RCU (URCU) के लिए 3 समाधान प्रदान करता है:

• Quiescent-State-based Reclamation RCU पाठकों के लिए एक बहुत ही हल्की योजना है, लेकिन इसके लिए आवश्यक है कि महत्वपूर्ण रीडिंग सेक्शन के बाहर के धागे समय-समय पर "मैं एक मौन अवस्था में हूँ" की घोषणा करता हूँ। यह समाधान सामान्य उद्देश्य पुस्तकालय के लिए उपयुक्त नहीं है, जो कि libcds है , इसलिए मैं इस पर विचार नहीं करूंगा।
• सामान्य प्रयोजन यूआरसीयू उपयोगकर्ता-अंतरिक्ष आरसीयू एक एल्गोरिथ्म है जो सामान्य कार्यान्वयन के लिए उपयुक्त है, जिसका मैं नीचे वर्णन करूंगा।
• सिग्नल हैंडलिंग के माध्यम से उपयोगकर्ता-स्पेस RCU भी एक दिलचस्प सिग्नल-आधारित एल्गोरिथ्म है (विंडोज के लिए लागू नहीं * निक्स-सिस्टम के लिए उपयुक्त)। Libcds लाइब्रेरी में कार्यान्वित, यह सामान्य-उद्देश्य RCU की तुलना में प्रदर्शन को थोड़ा खराब करता है। मैं इस लेख में इस पर विचार नहीं करूँगा, जो लोग रुचि रखते हैं, उन्हें M.Desnoyers'a निबंध और libc स्रोत स्रोत कोड के लिए भेजा जाता है।

सामान्य प्रयोजन URCU

M.Desnoyers URCU एल्गोरिथ्म को इतने विस्तार से और पूरी तरह से बताता है कि मैं केवल इसका अनुसरण कर सकता हूं, केवल कुछ चर और कार्यों के नाम को बदलकर ताकि वे उन लोगों के साथ मेल खाते हों जो लिबकार्ड में अपनाए गए हैं।

URCU स्कीमा दो चर को परिभाषित करता है:

 std::atomic<uint32_t> g_nGlobalCtl(1) ; struct thread_record { std::atomic<uint32_t> nThreadCtl; thread_record * pNext; thread_record(): nThreadCtl(0), pNext(nullptr) {} }; 

thread_record संरचना में थ्रेड के लिए डेटा स्थानीय होता है और ऐसी सभी ऑब्जेक्ट्स को RCU थ्रेड्स की सूची से जोड़ता है।
निचले 31 बिट्स nThreadCtl में URCU कॉल की घोंसले की गहराई के लिए एक काउंटर होता है (हाँ, URCU महत्वपूर्ण रीड सेक्शन के लगभग असीमित नेस्टिंग की अनुमति देता है), उच्च बिट उस समय की ग्रेस की पहचानकर्ता को निर्धारित करता है जब थ्रेड महत्वपूर्ण रीड सेक्शन में प्रवेश करता है। वर्णित योजना में, अनुग्रह अवधि के लिए केवल दो पहचानकर्ता पर्याप्त हैं।
वैश्विक चर g_nGlobalCtl उच्च बिट में वर्तमान ग्रेस पीरियड की पहचान होती है, कम बिट्स nThreadCtl के प्रति-थ्रेड वैरिएबल को इनिशियलाइज़ करने के लिए कार्य करते हैं और बदलते नहीं हैं।
महत्वपूर्ण रीडिंग सेक्शन से / में प्रवेश / निकलने के लिए access_unlock क्रमशः क्रमशः access_lock और access_unlock फ़ंक्शन का उपयोग करें:

 static uint32_t const c_nControlBit = 0x80000000; static uint32_t const c_nNestMask = c_nControlBit — 1; void access_lock() { thread_record * pRec = get_thread_record(); assert( pRec != nullptr ); uint32_t tmp = pRec->nThreadCtl.load( std::memory_order_relaxed ); if ( (tmp & c_nNestMask) == 0 ) { pRec->nThreadCtl.store(g_nGlobalCtl.load( std::memory_order_relaxed ), std::memory_order_relaxed ); std::thread_fence( std::memory_order_acquire ); } else pRec->nThreadCtl.fetch_add( 1, std::memory_order_relaxed ); } void access_unlock() { thread_record * pRec = get_thread_record(); assert( pRec != nullptr ); pRec->nThreadCtl.fetch_sub( 1, std::memory_order_release ); } 

URCU के महत्वपूर्ण अनुभाग में प्रवेश करने पर, यह जांचा जाता है कि कॉल नेस्टेड है या नहीं। यदि कॉल नेस्टेड है (यानी, निचले 31 बिट्स में काउंटर शून्य नहीं है), नेस्टिंग काउंटर को केवल इंक्रीमेंट किया गया है। यदि कॉल नेस्टेड नहीं है, तो वर्तमान थ्रेड के nThreadCtl वैरिएबल को ग्लोबल वैरिएबल g_nGlobalCtl का मान असाइन किया गया है; यह दर्शाता है कि महत्वपूर्ण खंड एक निश्चित अनुग्रह अवधि (उच्च बिट g_nGlobalCtl ) में दर्ज किया गया था, और निम्न बिट्स में इकाई g_nGlobalCtl वर्तमान स्ट्रीम के नेस्टिंग काउंटर को आरंभ करता है। सबसे पहले, महत्वपूर्ण अनुभाग में सबसे बाहरी प्रवेश, मेमोरी का अधिग्रहण-अवरोध लागू किया जाता है। यह गारंटी देता है कि बाद के कोड को प्रोसेसर या कंपाइलर द्वारा बाधा के ऊपर ("अनुकूलित") नहीं ले जाया जाएगा। यह सभी प्रोसेसरों के लिए स्ट्रीम की वर्तमान ग्रेस अवधि की दृश्यता सुनिश्चित करता है - यदि आप इस आदेश का उल्लंघन करते हैं, तो URCU एल्गोरिथम उखड़ जाएगा। नेस्टेड महत्वपूर्ण अनुभाग में प्रवेश करते समय, एक बाधा की आवश्यकता नहीं होती है, क्योंकि वर्तमान अनुग्रह अवधि (उच्च बिट) नहीं बदलती है।
महत्वपूर्ण खंड ( access_unlock ) से बाहर निकलते समय, वर्तमान थ्रेड के nThreadCtl में नेस्टिंग काउंटर को केवल घटाया जाता है। परमाणु ऑपरेशन के रिलीज शब्दार्थ को लागू किया जाता है; वास्तव में, एक रिलीज बैरियर की आवश्यकता यहाँ तभी होती है जब उच्चतम क्रिटिकल सेक्शन को छोड़ते समय (जब नेस्टिंग काउंटर से 1 से 0 की ओर बढ़ रहे हों), नेस्टेड क्रिटिकल सेक्शन को छोड़ते समय, आराम से सिमेंटिक्स पर्याप्त हो। काउंटर को रीसेट करते समय एक रिलीज अवरोध की आवश्यकता होती है क्योंकि जब नेस्टिंग काउंटर 1 से 0 तक जाता है, तो घोषणा वास्तव में "थ्रेड आरसीयू का उपयोग नहीं करता है", अर्थात, अनुग्रह अवधि बाहर निकल जाती है, जो URCU एल्गोरिदम के लिए महत्वपूर्ण है। संकलक या प्रोसेसर द्वारा आदेश का उल्लंघन एल्गोरिथ्म की अक्षमता की ओर ले जाएगा। कोड में "0 - नहीं 0" स्थितियों को पहचानने के लिए एक सशर्त संक्रमण की आवश्यकता होगी, जो कि access_unlock फ़ंक्शन में प्रदर्शन को जोड़ने की संभावना नहीं है, और URCU के महत्वपूर्ण खंडों का उपयोग करने के लिए मुख्य पैटर्न नेस्टिंग के बिना है, इसलिए सिमेंटिक को हमेशा यहां उपयोग किया जाता है।

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

लेखक थ्रेड को पहले यह सुनिश्चित करना चाहिए कि भौतिक रूप से आइटम को हटाने से पहले अनुग्रह अवधि पूरी हो गई है। अनुग्रह अवधि के अंत की शर्तें दो में से एक हैं:

• प्रत्येक थ्रेड का nThreadCtl बिट्स (नेस्टिंग काउंटर) nThreadCtl शून्य के बराबर है, जिसका अर्थ है कि धागा URCU के महत्वपूर्ण खंड में नहीं है
• nThreadCtl का उच्च बिट nThreadCtl के उच्च बिट से मेल नहीं खाता है, जिसका अर्थ है कि पाठक ग्रेस पीरियड की शुरुआत के बाद महत्वपूर्ण अनुभाग में प्रवेश करता है

इन शर्तों को निम्न फ़ंक्शन द्वारा जांचा जाता है:

 bool check_grace_period( thread_record * pRec ) { uint32_t const v = pRec->nThreadCtl.load( std::memory_order_relaxed ); return (v & general_purpose_rcu::c_nNestMask) && ((( v ^ g_nGlobalCtl.load( std::memory_order_relaxed )) & ~c_nNestedMask )); } 

भौतिक विलोपन से पहले, लेखक synchronize फ़ंक्शन को कॉल करता है, जो वर्तमान ग्रेस अवधि के अंत की अपेक्षा करता है:

 std::mutex g_Mutex ; void synchronize() { std::atomic_thread_fence( std::memory_order_acquire ); { cds::lock::scoped_lock<std::mutex> sl( g_Mutex ); flip_and_wait(); flip_and_wait(); } std::atomic_thread_fence( std::memory_order_release ); } 

यहाँ g_Mutex URCU एल्गोरिथ्म के लिए एक वैश्विक म्यूटेक्स है (हाँ, हाँ! URCU अभी भी एक तुल्यकालन तकनीक है, इसलिए म्यूटेक्स के बिना कहीं नहीं है)। इस प्रकार, केवल एक लेखक थ्रेड synchronize कर सकता है। यह मत भूलो कि आरसीयू "लगभग केवल पढ़ने के लिए" डेटा के लिए तैनात है, इसलिए इस म्यूटेक्स पर कोई विशेष क्रश की उम्मीद नहीं है।
लेखक flip_and_wait फ़ंक्शन को कॉल करके ग्रेस अवधि के अंत की उम्मीद करता है:

 void flip_and_wait() { g_nGlobalCtl.fetch_xor( c_nControlBit, std::memory_order_seq_cst ); for (thread_record* pRec = g_ThreadList.head(std::memory_order_acquire); pRec!= nullptr; pRec = pRec->m_pNext ) { while ( check_grace_period( pRec )) { sleep( 10 ); //  10  CDS_COMPILER_RW_BARRIER ; } } } 

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

flip_and_wait लेखक दो बार flip_and_wait क्यों flip_and_wait ? स्पष्टीकरण के लिए, दो धाराओं A और B के साथ क्रियाओं के इस क्रम पर विचार करें। मान लीजिए कि flip_and_wait को synchronize करने के लिए कॉल केवल एक है:

• access_lock A कॉल access_lock । इस फ़ंक्शन के शरीर में, यह निर्धारित किया जाता है कि कॉल नेस्टेड नहीं है, वैश्विक g_nGlobalCtl पढ़ा जाता है, लेकिन अभी तक इसे nThreadCtl चर nThreadCtl को नहीं सौंपा गया है (सब कुछ समानांतर में किया गया है, इसलिए यह स्थिति काफी स्वीकार्य है)
• थ्रेड बी कॉल्स को synchronize । पहला flip_and_wait , जो flip_and_wait में अनुग्रह अवधि पहचानकर्ता बिट को g_nGlobalCtl । वर्तमान अनुग्रह अवधि पहचानकर्ता 1 बन जाता है
• चूंकि URCU के महत्वपूर्ण खंड में कोई नहीं है (याद रखें कि थ्रेड ए ने अभी तक इसके चर nThreadCtl का मान निर्धारित नहीं किया है), थ्रेड बी पूर्ण हो जाता है synchronize
• nThreadCtl ए अपने वैरिएबल nThreadCtl असाइन करता है। स्मरण करो कि धारा अनुग्रह अवधि के पुराने मूल्य को पढ़ती है, 0 के बराबर
• access_lock ए access_lock समाप्त करता है और महत्वपूर्ण अनुभाग में निष्पादन जारी रखता है
• थ्रेड बी कॉल्स फिर से synchronize (जाहिर है, फिर से कुछ हटाना चाहते हैं)। फिर से, वर्तमान अनुग्रह अवधि g_nGlobalCtl में g_nGlobalCtl , इसलिए इसका पहचानकर्ता अब 0 है।

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

flip_and_wait दो बार कॉल करके, दो बार, ग्रेस पीरियड की समाप्ति की प्रतीक्षा करते हुए, हम उपरोक्त समस्या को हल करते हैं, जिसका कारण थ्रेड्स का प्रतिस्पर्धी निष्पादन है।

URCU परिवादों में कार्यान्वयन

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

Libcds लाइब्रेरी में पाँच URCU कार्यान्वयन हैं, जो सभी cds::urcu में रहते हैं cds::urcu :

• general_instant वर्णित URCU एल्गोरिथ्म के ठीक बाद में एक कार्यान्वयन है: प्रत्येक विलोपन synchronize कारण बनता है, कोई बफरिंग नहीं। यदि निष्कासन काफी बार-बार किया जाने वाला ऑपरेशन है, अर्थात, संरचना "लगभग-केवल पढ़ने योग्य" नहीं है, तो यह कार्यान्वयन धीमी गति से होता है
• general_buffered एक पूर्व-निर्धारित आकार के सामान्य लॉक-फ्री बफर के साथ एक कार्यान्वयन है। दिमित्री व्युकोव की कतार का उपयोग लॉक-फ्री बफर के रूप में किया जाता है - cds::container::VyukovMPMCCycleQueue । इस कार्यान्वयन का प्रदर्शन हैज़र्ड पॉइंटर के समान है
• general_threaded - general_threaded समान, लेकिन बफ़रिंग एक समर्पित थ्रेड द्वारा किया जाता है। समर्पित स्ट्रीम के साथ अतिरिक्त सिंक्रनाइज़ेशन के कारण यह कार्यान्वयन सामान्य से थोड़ा कम है, लेकिन यह लेखकों को धीमा नहीं करता है
• signal_buffered का एक एनालॉग है, लेकिन संकेत-आधारित URCU पर आधारित है। विंडोज सिस्टम के लिए नहीं
• signal_threaded - संकेत-नियंत्रित URCU के लिए general_threaded एनालॉग। विंडोज के लिए भी नहीं

URCU कार्यान्वयन की इतनी बहुतायत URCU के तहत कंटेनर विशेषज्ञता लिखने की समस्या को जन्म देती है। तथ्य यह है कि यूआरसीयू योजना के लिए कंटेनरों का कार्यान्वयन हेज़र्ड पॉइंटर के कार्यान्वयन से काफी अलग है। इसलिए, URCU के लिए एक अलग विशेषज्ञता की आवश्यकता है। मैं एक विशेषज्ञता लेना चाहूंगा, पांच नहीं।
URCU के तहत विशेषज्ञता लिखने की सुविधा के लिए, आवरण वर्ग cds::urcu::gc पेश किया गया था:

 template <typename RCUimpl> class gc; 

जहां RCUimpl के कार्यान्वयन में से एक है: general_instant , general_buffered , आदि ऐसे आवरण होने के बाद, general_buffered लिए एक विशेषज्ञता लिखना आसान है और यह केवल एक ही होगा:

 template < class RCU, typename Key, typename Value, class Traits > class SplitListMap< cds::urcu::gc< RCU >, Key, Value, Traits > ... 

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

सूचीबद्ध URCU एल्गोरिदम के सभी तरीके से लागू किए गए हैं: प्रत्येक के लिए, एक वैश्विक सिंगलटन ऑब्जेक्ट है, जिसे आवरण cds::urcu::gc<cds::urcu::general_buffered<> > के कंस्ट्रक्टर को कॉल करके इनिशियलाइज़ किया जाता है cds::urcu::gc<cds::urcu::general_buffered<> > main() की शुरुआत में main() , कॉल करने के बाद cds::Initialize() :

 #include <cds/init.h> //cds::Initialize  cds::Terminate #include <cds/gc/general_buffered.h> // general_buffered URCU int main(int argc, char** argv) { //  libcds cds::Initialize() ; { //  general_buffered URCU  cds::urcu::gc<cds::urcu::general_buffered<> > gbRCU ; //  main thread  lock-free  // main thread    //   libcds cds::threading::Manager::attachThread() ; // , libcds    //     ... } //  libcds cds::Terminate() ; } 

हेज़र्ड पॉइंटर योजना की तरह, URCU कंटेनरों का उपयोग करने वाले प्रत्येक धागे को एक विशेष तरीके से आरंभ किया जाना चाहिए:

 // cds::threading::Manager #include <cds/threading/model.h> int myThreadEntryPoint(void *) { //     libcds cds::threading::Manager::attachThread() ; //        // lock-free  libcds ... //    libcds cds::threading::Manager::detachThread() ; return 0; } 

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

यदि आप libcds से URCU के कार्यान्वयन के आधार पर, अपना खुद का कंटेनर वर्ग बनाने का निर्णय लेते हैं, तो आपको पुस्तकालय के URCU- कंटेनरों के आंतरिक उपकरण के बारे में विस्तार से समझना चाहिए। सिद्धांत रूप में, अलौकिक कुछ भी नहीं है: विधि में प्रवेश करते समय, हम gc::access_lock() , जब हम बाहर निकलते हैं, तो हम gc::access_unlock() (यहाँ gc URCU कार्यान्वयनों में से एक है; अपवादों की सुरक्षा के लिए, कॉलिंग फ़ंक्शंस के बजाय स्कॉप्ड लॉक तकनीक का उपयोग करना बेहतर है) । केवल सूक्ष्म बिंदु किसी तत्व को हटा रहा है: डिलीट करने का तरीका महत्वपूर्ण रीडिंग सेक्शन में भी होना चाहिए, लेकिन gc::retire_ptr कॉल करके एलिमेंट का भौतिक निष्कासन gc::retire_ptr को महत्वपूर्ण सेक्शन के बाहर किया जाना चाहिए, अन्यथा डेडलॉक संभव है: अंदर gc::retire_ptr को synchronize कर सकते हैं।

Libcds सभी सेट और मैप कक्षाओं के लिए URCU विशेषज्ञता को परिभाषित करता है। कतार और स्टैक कंटेनर के लिए URCU विशेषज्ञता अपरिभाषित हैं - वे "लगभग केवल-पढ़ने के लिए" कंटेनर नहीं हैं, इसलिए URCU उनके लिए नहीं हैं।