"लॉक-फ़्री, या लॉक-फ़्री नहीं, यह सवाल है" या "स्वस्थ नींद कड़वी मूली से भी बदतर है"

" कैसे सही ढंग से और गलत तरीके से सोना है " लेख पर टिप्पणियों ने मुझे इस लेख को लिखने के लिए प्रेरित किया।

यह आलेख बहु-थ्रेडेड अनुप्रयोगों के विकास पर ध्यान केंद्रित करेगा, LAppS पर काम करने की प्रक्रिया में उत्पन्न होने वाले कुछ मामलों के लॉक-फ़्री की प्रयोज्यता , कार्य शेड्यूलर के खिलाफ नैनोसेलेप फ़ंक्शन और हिंसा।

NB:      C++  Linux,       POSIX.1-2008  a (    ). 

सामान्य तौर पर, सब कुछ बहुत गड़बड़ है, मुझे उम्मीद है कि प्रस्तुति में विचार की ट्रेन स्पष्ट होगी। अगर दिलचस्पी है, तो मैं एक बिल्ली के लिए पूछता हूं।

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

LAppS म्यूटेक्स और सेमाफोर का उपयोग बहुत सक्रिय रूप से करता है। इसी समय, सी ++ मानक में कोई सीमैफ़ोर्स नहीं हैं। तंत्र बहुत महत्वपूर्ण और सुविधाजनक है, लेकिन सी ++ को उन प्रणालियों पर काम करना चाहिए जो सेमीफ़ोर्स का समर्थन नहीं करते हैं, और इसलिए सेमीफ़ोर्स मानक में शामिल नहीं हैं। इसके अलावा, अगर मैं सेमाफोर का उपयोग करता हूं क्योंकि वे सुविधाजनक हैं, तो म्यूटेक्स क्योंकि मुझे करना है।

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

और मैंने यह जांचने का फैसला किया कि क्या मैं std :: mutex और POSIX सेमाफोरेस को मना कर सकता हूं, उन्हें std :: atomic के साथ अनुकरण करते हुए, लोड को ज्यादातर उपयोगकर्ताभूमि में स्थानांतरित कर रहा हूं। वास्तव में असफल रहा, लेकिन पहली चीजें पहले।

सबसे पहले, मेरे पास कई खंड हैं जिनमें ये प्रयोग उपयोगी हो सकते हैं:

• लिब्रेएसएसएल (केस 1) में ताले;
• अवरुद्ध जब पेलोड प्राप्त करने के लिए Lua अनुप्रयोगों (मामला 2) के पैकेट प्राप्त;
• लूआ अनुप्रयोगों (केस 3) द्वारा संसाधित होने के लिए तैयार पेलोड घटनाओं की प्रतीक्षा की जा रही है।

चलो गैर-अवरुद्ध-ताले से शुरू करते हैं। आइए एटमिक्स का उपयोग करके हमारे म्यूटेक्स को लिखें, जैसा कि एच। सटर द्वारा कुछ भाषणों में दिखाया गया है (इसलिए कोई मूल कोड नहीं है, इसलिए, स्मृति से और इसलिए कोड मूल 100% के साथ मेल नहीं खाता है, और Satter में यह कोड C ++ 20 प्रगति से संबंधित था, इसलिए मतभेद हैं)। और इस कोड की सादगी के बावजूद, इसमें नुकसान हैं।

 #include <atomic> #include <pthread.h> namespace test { class mutex { private: std::atomic<pthread_t> mLock; public: explicit mutex():mLock{0} { } mutex(const mutex&)=delete; mutex(mutex&)=delete; void lock() { pthread_t locked_by=0; //  C++20     , .. compare_exchange_strong          while(!mLock.compare_exchange_strong(locked_by,pthread_self())) { locked_by=0; //      } } void unlock() { pthread_t current=pthread_self(); if(!mLock.compare_exchange_strong(current,0)) { throw std::system_error(EACCES, std::system_category(), "An attempt to unlock the mutex owned by other thread"); } } const bool try_lock() { pthread_t unused=0; return mLock.compare_exchange_strong(unused,pthread_self()); } }; } 

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

हम शेड्यूल_यिल्ड () का उपयोग कर सकते हैं (जैसा कि ऊपर दिए गए लेखों में से एक में सुझाव दिया गया है)। क्या यह इतना आसान है? सबसे पहले, समय-सारणी () का उपयोग करने के लिए, यह आवश्यक है कि निष्पादन के सूत्र कार्य अनुसूची में उनकी प्राथमिकता के लिए SCHED_RR, SCHED_FIFO नीतियों का उपयोग करें। अन्यथा, कॉल करने के लिए शेड्यूल_डिल्ड () सीपीयू संसाधनों की बर्बादी होगी। दूसरे, शेड्यूल_इल्ड () के लिए एक बहुत ही लगातार कॉल अभी भी सीपीयू की खपत में वृद्धि करेगा। इसके अलावा, आपके आवेदन में वास्तविक समय की नीतियों का उपयोग, और बशर्ते कि सिस्टम में कोई अन्य वास्तविक समय अनुप्रयोग नहीं हैं, केवल आपके थ्रेड्स के लिए चयनित नीति के साथ अनुसूचक कतार को सीमित करेगा। ऐसा लगेगा कि यह अच्छा है! नहीं, अच्छा नहीं। पूरा सिस्टम कम संवेदनशील हो जाएगा, क्योंकि प्राथमिकता कार्य के साथ व्यस्त। पेन में सीएफक्यू होगा। लेकिन आवेदन में अन्य धागे हैं, और बहुत बार एक स्थिति उत्पन्न होती है जब म्यूटेक्स पर कब्जा करने वाले धागे को कतार के अंत में डाल दिया जाता है (कोटा समाप्त हो गया है), और जो धागा म्यूटेक्स के इंतजार में है उसके ठीक सामने जारी किया गया है। मेरे प्रयोगों (केस 2) में, इस पद्धति ने std :: mutex की तुलना में समान परिणामों (3.8% खराब) के बारे में जानकारी दी, लेकिन यह प्रणाली कम उत्तरदायी है और CPU खपत में 5% -7% की वृद्धि हुई है।

आप परीक्षण बदलने की कोशिश कर सकते हैं :: म्यूटेक्स :: लॉक () इस तरह (भी खराब):

 void lock() { pthread_t locked_by=0; while(!mLock.compare_exchange_strong(locked_by,pthread_self())) { static thread_local const struct timespec pause{0,4}; // -      nanosleep(&pause,nullptr); locked_by=0; } } 

यहां आप नैनोसेकंड में नींद की अवधि के साथ प्रयोग कर सकते हैं, 4ns देरी मेरे सीपीयू के लिए इष्टतम थे और एसटी के लिए प्रदर्शन ड्रॉप के सापेक्ष प्रदर्शन :: mutex एक ही मामले में 2 1.2% था। तथ्य यह नहीं है कि नैनोसेलेप 4ns सोए थे। वास्तव में, या अधिक (सामान्य मामले में) या उससे कम (यदि बाधित हो)। सीपीयू की खपत में गिरावट (!) 12% -20% थी। यानी यह एक स्वस्थ सपना था।

ओपनएसएसएल और लिब्रेएसएसएल के दो कार्य हैं जो इन पुस्तकालयों का उपयोग बहु-थ्रेडेड वातावरण में करते समय ब्लॉक करने के लिए कॉलबैक की स्थापना करते हैं। यह इस तरह दिखता है:

 //  callback void openssl_crypt_locking_function_callback(int mode, int n, const char* file, const int line) { static std::vector<std::mutex> locks(CRYPTO_num_locks()); if(n>=static_cast<int>(locks.size())) { abort(); } if(mode & CRYPTO_LOCK) locks[n].lock(); else locks[n].unlock(); } //  callback-a CRYPTO_set_locking_callback(openssl_crypt_locking_function_callback); //  id CRYPTO_set_id_callback(pthread_self); 

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

सामान्य तौर पर, हम केस 2 और केस 1 को हटाते हैं, और std :: mutex के साथ बने रहते हैं।

आइए अर्धवृत्त पर जाएं। Std :: condition_variable का उपयोग करके सेमाफोर को कैसे लागू किया जाए, इसके कई उदाहरण हैं। वे सभी std :: mutex का उपयोग करते हैं। और इस तरह के सेमाफोर सिमुलेटर पॉसिक्स सिस्टम सेमाफोर्स की तुलना में धीमे (मेरे परीक्षणों के अनुसार) हैं।

इसलिए, हम परमाणुओं पर एक अर्धवृत्त बनाएंगे:

  class semaphore { private: std::atomic<bool> mayRun; mutable std::atomic<int64_t> counter; public: explicit semaphore() : mayRun{true},counter{0} { } semaphore(const semaphore&)=delete; semaphore(semaphore&)=delete; const bool post() const { ++counter; return mayRun.load(); } const bool try_wait() { if(mayRun.load()) { if(counter.fetch_sub(1)>0) return true; else { ++counter; return false; } }else{ throw std::system_error(ENOENT,std::system_category(),"Semaphore is destroyed"); } } void wait() { while(!try_wait()) { static thread_local const struct timespec pause{0,4}; nanosleep(&pause,nullptr); } } void destroy() { mayRun.store(false); } const int64_t decrimentOn(const size_t value) { if(mayRun.load()) { return counter.fetch_sub(value); }else{ throw std::system_error(ENOENT,std::system_category(),"Semaphore is destroyed"); } } ~semaphore() { destroy(); } }; 

ओह, यह सेमाफोर सिस्टम सेमाफोर से कई गुना तेज है। एक प्रदाता और 20 कंस्यूमर्स के साथ इस सेमाफोर के एक अलग परीक्षण का परिणाम:

 OS semaphores test. Started 20 threads waiting on a semaphore Thread(OS): wakes: 500321 Thread(OS): wakes: 500473 Thread(OS): wakes: 501504 Thread(OS): wakes: 502337 Thread(OS): wakes: 498324 Thread(OS): wakes: 502755 Thread(OS): wakes: 500212 Thread(OS): wakes: 498579 Thread(OS): wakes: 499504 Thread(OS): wakes: 500228 Thread(OS): wakes: 499696 Thread(OS): wakes: 501978 Thread(OS): wakes: 498617 Thread(OS): wakes: 502238 Thread(OS): wakes: 497797 Thread(OS): wakes: 498089 Thread(OS): wakes: 499292 Thread(OS): wakes: 498011 Thread(OS): wakes: 498749 Thread(OS): wakes: 501296 OS semaphores test. 10000000 of posts for 20 waiting threads have taken 9924 milliseconds OS semaphores test. Post latency: 0.9924ns ======================================= AtomicEmu semaphores test. Started 20 threads waiting on a semaphore Thread(EmuAtomic) wakes: 492748 Thread(EmuAtomic) wakes: 546860 Thread(EmuAtomic) wakes: 479375 Thread(EmuAtomic) wakes: 534676 Thread(EmuAtomic) wakes: 501014 Thread(EmuAtomic) wakes: 528220 Thread(EmuAtomic) wakes: 496783 Thread(EmuAtomic) wakes: 467563 Thread(EmuAtomic) wakes: 608086 Thread(EmuAtomic) wakes: 489825 Thread(EmuAtomic) wakes: 479799 Thread(EmuAtomic) wakes: 539634 Thread(EmuAtomic) wakes: 479559 Thread(EmuAtomic) wakes: 495377 Thread(EmuAtomic) wakes: 454759 Thread(EmuAtomic) wakes: 482375 Thread(EmuAtomic) wakes: 512442 Thread(EmuAtomic) wakes: 453303 Thread(EmuAtomic) wakes: 480227 Thread(EmuAtomic) wakes: 477375 AtomicEmu semaphores test. 10000000 of posts for 20 waiting threads have taken 341 milliseconds AtomicEmu semaphores test. Post latency: 0.0341ns 

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

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

लेकिन LAppS में 3 के मामले में इसका उपयोग करने से नींद के समय की परवाह किए बिना प्रदर्शन हानि होती है। वह अक्सर जाँच करने के लिए उठता है, और LAppS में होने वाली घटनाएँ बहुत धीमी (नेटवर्क विलंबता, विलंबता उत्पन्न करने वाले ग्राहक पक्ष की विलंबता, आदि) तक पहुँचती हैं। और कम बार चेक करने का मतलब है प्रदर्शन का कम होना।

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

एक सिस्टम म्यूटेक्स और सेमाफोर का लाभ यह है कि निष्पादन थ्रेड तब तक नहीं उठता है जब तक कि कोई घटना (म्यूटेक्स को अनलॉक करने या सेमाफोर को बढ़ाने) नहीं होती है। अतिरिक्त सीपीयू चक्र बर्बाद नहीं होते हैं - लाभ।

सामान्य तौर पर, इस बुराई से सब कुछ, मेरे सिस्टम पर iptables को अक्षम करने से 12% (TLS के साथ) से 30% (TLS के बिना) एक प्रदर्शन लाभ होता है ...