क्या बूस्ट:: थ्रेड और बूस्ट:: mutex को c++ 11 समकक्षों के साथ प्रतिस्थापित करना स्मार्ट है?




multithreading c++11 (4)

बूस्ट के बीच कई अंतर हैं। थ्रेड और सी ++ 11 मानक थ्रेड लाइब्रेरी:

  • बूस्ट थ्रेड रद्दीकरण का समर्थन करता है, सी ++ 11 धागे नहीं करते हैं
  • सी ++ 11 std::async का समर्थन करता है, लेकिन बूस्ट नहीं करता है
  • बूस्ट में एक boost::shared_mutex एकाधिक-पाठक / सिंगल-लेखक लॉकिंग के लिए है। समान std::shared_timed_mutex केवल C ++ 14 ( N3891 ) के बाद उपलब्ध है, जबकि std::shared_mutex केवल C ++ 17 ( N4508 ) के बाद उपलब्ध है।
  • सी ++ 11 टाइमआउट बूस्ट टाइमआउट्स के लिए अलग हैं (हालांकि इसे जल्द ही बूस्ट बदलना चाहिए। क्रोनो स्वीकार कर लिया गया है)।
  • कुछ नाम अलग हैं (उदाहरण के लिए boost::unique_future बनाम std::future )
  • std::thread तर्क-गुजरने वाले अर्थशास्त्र को boost::thread लिए अलग हैं boost::thread --- बूस्ट बूस्ट boost::bind का उपयोग करता है, जिसके लिए प्रतिलिपि तर्क की आवश्यकता होती है। std::thread move-only प्रकारों जैसे std::unique_ptr को तर्क के रूप में पारित करने की अनुमति देता है। boost::bind के उपयोग के कारण, नेस्टेड बाइंड एक्सप्रेशन में _1 जैसे प्लेसहोल्डर्स के अर्थशास्त्र अलग-अलग हो सकते हैं।
  • यदि आप स्पष्ट रूप से join() या detach() तो boost::thread विनाशक और असाइनमेंट ऑपरेटर थ्रेड ऑब्जेक्ट को नष्ट / असाइन किए जाने पर detach() को कॉल करेगा। सी ++ 11 std::thread ऑब्जेक्ट के साथ, इसके परिणामस्वरूप std::terminate() को कॉल किया जाएगा और एप्लिकेशन को निरस्त कर दिया जाएगा।

केवल- std::unique_ptr पैरामीटर के बारे में बिंदु को स्पष्ट करने के लिए, निम्नलिखित मान्य C ++ 11 है, और अस्थायी std::unique_ptr से int के स्वामित्व को नया थ्रेड प्रारंभ होने पर f1 के पैरामीटर में स्थानांतरित करता है। हालांकि, अगर आप boost::thread उपयोग करते हैं तो यह काम नहीं करेगा, क्योंकि यह आंतरिक रूप से boost::bind का उपयोग करता है, और std::unique_ptr प्रतिलिपि नहीं बनाई जा सकती है। जीसीसी के साथ प्रदान की गई सी ++ 11 थ्रेड लाइब्रेरी में भी एक बग है जो इस काम को रोकती है, क्योंकि यह वहां भी कार्यान्वयन में std::bind का उपयोग करती है।

void f1(std::unique_ptr<int>);
std::thread t1(f1,std::unique_ptr<int>(new int(42)));

यदि आप बूस्ट का उपयोग कर रहे हैं तो यदि आप अपने कंपाइलर का समर्थन करते हैं तो आप शायद सी ++ 11 धागे को अपेक्षाकृत दर्द रहित रूप से स्विच कर सकते हैं (उदाहरण के लिए लिनक्स पर जीसीसी के हाल के संस्करणों में सी ++ 11 थ्रेड लाइब्रेरी का सबसे अधिक कार्यान्वयन है -std=c++0x मोड)।

यदि आपका कंपाइलर सी ++ 11 थ्रेड का समर्थन नहीं करता है तो आप जस्ट :: थ्रेड जैसे तृतीय-पक्ष कार्यान्वयन प्राप्त कर सकते हैं, लेकिन यह अभी भी एक निर्भरता है।

प्रेरणा: कारण मैं इस पर विचार कर रहा हूं कि मेरा प्रतिभा प्रोजेक्ट मैनेजर सोचता है कि बढ़ावा एक और निर्भरता है और यह भयानक है क्योंकि "आप इस पर निर्भर करते हैं" (मैंने बढ़ावा की गुणवत्ता की व्याख्या करने की कोशिश की, फिर कुछ समय बाद छोड़ दिया :( )। छोटे कारण यह है कि मैं ऐसा क्यों करना चाहता हूं कि मैं सी ++ 11 फीचर्स सीखना चाहूंगा, क्योंकि लोग इसमें कोड लिखना शुरू कर देंगे। इसलिए:

  1. #include<thread> #include<mutex> बीच 1: 1 मैपिंग है और समकक्षों को बढ़ावा देता है?
  2. क्या आप सी ++ 11 के साथ बूस्ट स्टफ को प्रतिस्थापित करने के लिए एक अच्छा विचार मानेंगे
    सामान। मेरा उपयोग आदिम है, लेकिन क्या ऐसे उदाहरण हैं जब std प्रस्ताव नहीं देता है कि क्या बढ़ावा देता है? या (निंदा) इसके विपरीत?

पीएस मैं जीसीसी का उपयोग करता हूं इसलिए हेडर वहां हैं।


मैंने बूस्ट के बजाय std से shared_ptr का उपयोग करने की कोशिश की और मुझे वास्तव में इस वर्ग के जीसीसी कार्यान्वयन में एक बग मिला। मेरा आवेदन दो बार बुलाए जाने वाले विनाशक के कारण दुर्घटनाग्रस्त हो रहा था (यह वर्ग थ्रेड-सुरक्षित होना चाहिए और ऐसी समस्याओं को उत्पन्न नहीं करना चाहिए)। बढ़ावा देने के बाद :: shared_ptr सभी समस्याएं गायब हो गईं। सी ++ 11 के वर्तमान कार्यान्वयन अभी भी परिपक्व नहीं हैं।

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

संक्षेप में - यदि आपके पास बूस्ट का उपयोग करके पहले से लिखा गया एक एप्लीकेशन है, तो अपने कोड को रखना सुरक्षित है क्योंकि यह सी ++ 11 मानक में जाने में कुछ प्रयास करने की बजाय है।


std::thread पर माइग्रेट न करने का एक कारण है।

यदि आप स्थैतिक लिंकिंग का उपयोग कर रहे हैं, तो इन gcc कीड़े / सुविधाओं के कारण std::thread अनुपयोगी हो जाता है:

अर्थात्, यदि आप std::thread::detach या std::thread::join कॉल करते हैं तो इसमें अपवाद या क्रैश हो जाएगा, जबकि इन मामलों में boost::thread ठीक काम करता है।


std::thread बड़े पैमाने पर boost::thread बाद मॉडलिंग किया जाता है, कुछ मतभेदों के साथ :

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

यह 2007 से है, इसलिए कुछ बिंदु अब मान्य नहीं हैं: boost::thread में अब native_handle फ़ंक्शन है, और, जैसा कि native_handle इंगित करते हैं, std::thread को अब रद्दीकरण नहीं होता है।

मुझे boost::mutex और std::mutex बीच कोई महत्वपूर्ण अंतर नहीं मिला।





mutex