के लिए एक आरडब्ल्यू लॉक मैं बूस्ट के बजाय नए मानक धागे का उपयोग करना चाहता हूं: धागे लेकिन मैंने देखा है कि पुराना shared_mutex उपलब्ध नहीं है। इस कार्यक्षमता को प्रतिस्थापित करने और मुझे एक बहु-पाठक, सिंगल-लेखक लॉक देने के लिए एक अच्छी सिफारिश क्या होगी?सी ++ 11 धागे
std::shared_mutex सी ++ 14 मानक पुस्तकालय का हिस्सा होगा। यह इसे सी ++ 11 में नहीं बनाया गया क्योंकि सिर्फ एक प्रस्ताव तैयार करने और इसे पूरी तरह से चर्चा करने का कोई समय नहीं था।
हालांकि आप अभी भी boost::shared_mutex का उपयोग कर सकते हैं। विंडोज के तहत, यदि आप विंडोज विस्टा या बाद में काम कर रहे हैं, तो आप Slim Read-Write Locks का उपयोग कर सकते हैं, जो गति और स्मृति खपत के लिए अनुकूलित हैं।
आप विशेष रूप से ढेर अतिप्रवाह सवाल "C++11 equivalent to boost shared_mutex" पर एक नज़र रखना चाहिए, और निम्न लिंक किया गया ईमेल बातचीत: http://permalink.gmane.org/gmane.comp.lib.boost.devel/211180 (जो अनुमोदन shared_mutex लिए सी ++ 11 समिति के प्रतिरोध बताते हैं)। जो डफी के वेबलॉग पर भी निम्नलिखित प्रयोग: http://www.bluebytesoftware.com/blog/2009/02/12/ReaderwriterLocksAndTheirLackOfApplicabilityToFinegrainedSynchronization.aspx।
हर बार जब आप पाठक/लेखक लॉक पर विचार कर रहे होते हैं, तो अपने आप से निम्नलिखित 6 प्रश्न पूछें। यदि आप उनमें से किसी के लिए "नहीं" का उत्तर दे सकते हैं तो पाठक/लेखक ताले आपके प्रोग्राम को और भी बेहतर बनाने जा रहे हैं, बेहतर नहीं।
const है? मैंने सही उपयोगों से अपने जीवन में shared_mutex के अधिक गलत उपयोग किए हैं। shared_mutex का उपयोग करने के लिए सही ढंग से होना चाहिए यदि आप किसी भी कंपाइलर शिकायतों के बिना पाठक महत्वपूर्ण अनुभाग के अंदर अपनी साझा वस्तुओं const घोषित कर सकते हैं। एक "उपभोक्ता" "कोई है जो डेटा संरचना को बिल्कुल परिवर्तित नहीं करता है" के बराबर है।const कॉल के आस-पास रिटर्न ऑब्जेक्ट को मालिश करने के लिए प्रारंभिक कार्य और/या काम का एक समूह होता है। साझा ऑब्जेक्ट के अंतिम उपयोग से साझा ऑब्जेक्ट के पहले उपयोग से डेटा-निर्भरता पथ पर उस अतिरिक्त कार्य का अधिकांश महत्वपूर्ण भाग के बाहर स्थानांतरित नहीं किया जा सकता है।हालांकि वह पेज जो जो डफी को सावधानी बरतने की जरूरत है। यह धारणा है कि _one_ विशेष प्रकार के आरडब्ल्यू-लॉक (.NET में) के _one_ कार्यान्वयन के कारण सामान्य रूप से आरडब्ल्यू-लॉक पर बहुत अधिक असर नहीं पड़ता है। एक आरडब्ल्यू-लॉक एक महत्वपूर्ण खंड ऑब्जेक्ट से धीमा होने के लिए _have नहीं है और यह सीएएस संचालन का उपयोग करने के लिए _have नहीं है। इतने सारे बदलाव हैं, उदाहरण के लिए यह उचित नहीं है (या, यह _might_ है)। स्थिति के आधार पर, आरडब्ल्यू-ताले एक म्यूटेक्स की तुलना में बेहद अधिक कुशल (परिमाण के 2-3 आदेश) हो सकते हैं। आर/डब्ल्यू अनुपात पर लेना भी मजाकिया है ... – Damon
... 1 से 20 अनुपात पर लेना मजाकिया भी है। यह वास्तव में कुछ विशेष रूप से विशेष नहीं है। किसी कार्य के लिए गलत उपकरण का उपयोग करना निश्चित रूप से सर्वोत्तम माध्यमिक परिणामों पर देता है। यह शिकायत करने की तरह है कि 'std :: list' का उपयोग यादृच्छिक पहुंच पर खराब प्रदर्शन करता है, या 'std :: vector' मोर्चे पर लाखों तत्व डालने पर खराब प्रदर्शन करता है। यदि आपका पढ़ना आपके लिखने से अधिक नहीं है, तो निश्चित रूप से, निश्चित रूप से आरडब्ल्यू-लॉक कोई जीत नहीं है (और संभवतः एक नुकसान)। लेकिन वह गलत उपकरण का उपयोग कर रहा है। – Damon
प्रत्येक 0.25ms (= 250,000ns) में आने वाले एक अनुरोध का डफी का उदाहरण भी एक अच्छा है। यह एक "पूरी तरह से शून्य भीड़" मामला है। सीएएस ऑपरेशन की अत्यधिक लागत के बारे में भी सोचना (जो आमतौर पर 25ns से कम है) उस संदर्भ में मुझे मजाकिया बनाता है। प्रति सेकंड 4000 परमाणु संचालन करके एक आधुनिक सीपीयू को चुनौती नहीं दी जाती है। – Damon
मुझे लगता है कि एक बेहतर डुप्लिकेट https://stackoverflow.com/q/14306797/783510 होगा। वर्तमान डुप्लिकेट एक हाथ से लुढ़काए कार्यान्वयन के लिए पूछता है, जबकि दूसरा एक मानक पढ़ने/लेखक ताला के लिए पूछता है। –