क्या सी ++ 11 परमाणु <T> एमएमएपी के साथ प्रयोग योग्य है?

Question

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

चूंकि मैं नहीं चाहता हूं कि आंशिक लिखने वाले मूल्यों की दृश्यता के कारण लिखने के लिए, मैं std::atomic<bool> और std::atomic<int> का उपयोग करने की सोच रहा था। हालांकि, मुझे चिंता है कि std::atomic<T> को इस तरह कार्यान्वित किया जा सकता है कि केवल सी ++ 11 थ्रेड के साथ काम करता है और कई प्रक्रियाओं के साथ नहीं (संभावित रूप से, ओएस थ्रेड्स के साथ भी नहीं)। विशेष रूप से, यदि कार्यान्वयन साझा स्मृति ब्लॉक के बाहर संग्रहीत किसी भी डेटा संरचना का उपयोग करता है, तो बहु-प्रक्रिया परिदृश्य में यह असफल हो जाता है।

परमाणु अभिन्न विशेषज्ञताओं और विशेषज्ञता atomic<bool> मानक लेआउट होगा:

मैं कुछ आवश्यकताओं जो होने के लिए सुझाव है कि देखते हैं कि std::atomic अतिरिक्त डेटा के लिए एक एम्बेडेड ताला वस्तु या सूचक पकड़ नहीं होगा। वे प्रत्येक के पास एक छोटा डिफ़ॉल्ट कन्स्ट्रक्टर और एक छोटा विनाशक होगा। वे प्रत्येक समग्र प्रारंभिक वाक्यविन्यास का समर्थन करेंगे।

परमाणु वर्ग टेम्पलेट के सूचक आंशिक विशेषज्ञता होगी। इन विशेषज्ञताओं में मानक लेआउट, तुच्छ डिफ़ॉल्ट डिफॉल्ट कन्स्ट्रक्टर और छोटे विनाशक होंगे। वे प्रत्येक समग्र प्रारंभिक वाक्यविन्यास का समर्थन करेंगे।

तुच्छ डिफ़ॉल्ट निर्माण और विनाश मुझे लगता जुड़े करने के लिए बाहर निकालने के प्रति-वस्तु डेटा, चाहे वस्तु के अंदर संग्रहित, एक सूचक सदस्य चर के माध्यम से, या एक बाहरी मानचित्रण के माध्यम से।

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

atomic<T> का कार्यान्वयन उन चीजों को करने की अनुमति है जो अंतर-प्रक्रिया साझा स्मृति के साथ असंगत हैं, या ऐसे अन्य नियम हैं जो इसे सुरक्षित बनाते हैं?

---

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

किसी भी मामले में, किसी साझा क्षेत्र में प्रत्येक चर के लिए atomic_init पर एक कॉल की गारंटी करना मुश्किल लगता है ... इसलिए मुझे लगता है कि मुझे सी ++ 11 परमाणु प्रकारों से दूर जाना होगा।

Answer 1

मुझे दो महीने देर हो चुकी है, लेकिन मुझे अभी भी वही समस्या है और मुझे लगता है कि मुझे कुछ जवाब मिल गया है। लघु संस्करण यह है कि इसे काम करना चाहिए, लेकिन मुझे यकीन नहीं है कि मैं इस पर निर्भर करता हूं।

यहाँ मैं क्या मिला है:

• सी ++ 11 मानक एक नया स्मृति मॉडल को परिभाषित करता है, लेकिन यह "प्रक्रिया" ओएस-स्तर का बोध भी नहीं है, इसलिए कुछ भी बहु से संबंधित गैर मानक है ।

  [नोट:

• हालांकि, खंड 29.4 मानक के "लॉक मुक्त संपत्ति" (या कम से कम मसौदा मेरे पास है, N3337) इस नोट के साथ समाप्त होता संचालन, जो ताला मुक्त कर रहे हैं चाहिए पता-मुक्त भी हो। यही है, दो अलग-अलग पतों के माध्यम से उसी स्मृति स्थान पर परमाणु संचालन परमाणु रूप से संवाद करेगा। कार्यान्वयन किसी भी प्रति-प्रक्रिया स्थिति पर निर्भर नहीं होना चाहिए। यह प्रतिबंध स्मृति द्वारा संचार को सक्षम बनाता है जिसे प्रक्रिया में एक से अधिक बार और स्मृति द्वारा दो प्रक्रियाओं के बीच साझा किया जाता है। - अंत नोट]

  यह बहुत ही आशाजनक लगता है। :)

• कि ध्यान दें N2427 से आने के लिए है, जो और भी अधिक स्पष्ट है प्रकट होता है:

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

  तो ऐसा लगता है कि हाँ, सभी लॉक-फ्री ऑपरेशंस को इस सटीक परिदृश्य में काम करना चाहिए।

• अब, std::atomic<type> पर संचालन परमाणु हैं लेकिन वे प्लेटफार्म की क्षमताओं के आधार पर विशेष type के लिए लॉक-फ्री हो सकते हैं या नहीं भी हो सकते हैं। और हम x.is_lock_free() पर कॉल करके किसी भी चर x को देख सकते हैं।

• तो मैंने क्यों लिखा कि मैं इस पर निर्भर नहीं हूं? मुझे जीसीसी, एलएलवीएम या किसी और के लिए किसी भी प्रकार का दस्तावेज नहीं मिल रहा है जो इस बारे में स्पष्ट है।

Answer 2

सी ++ 11 तक, मानक ने यह निर्दिष्ट नहीं किया कि कितने धागे स्मृति साझा करते हैं, इसलिए हमने कार्यान्वयन-विशिष्ट व्यवहार पर निर्भर कई धागे वाले प्रोग्राम लिखे। मानक अभी भी निर्दिष्ट नहीं करता है कि साझा मेमोरी के साथ प्रक्रियाएं कैसे - या यदि आप चाहें, थ्रेड जो केवल आंशिक रूप से स्मृति साझा करते हैं - बातचीत करें। जो कुछ भी आप कर रहे हैं, वह कार्यान्वयन-विशिष्ट गारंटी पर निर्भर करेगा।

यह कहा गया है कि, मुझे लगता है कि प्रक्रिया-साझा स्मृति का समर्थन करने वाला एक कार्यान्वयन प्रक्रिया सिंक्रनाइज़ेशन के लिए प्रक्रिया-साझा स्मृति में उपयोग किए जाने वाले परमाणु जैसे थ्रेड सिंक्रनाइज़ेशन तंत्र को बनाने का प्रयास करेगा। कम से कम, मुझे लगता है कि एक std :: परमाणु विशेषज्ञता के लॉक-मुक्त कार्यान्वयन को बनाना मुश्किल होगा जो सही ढंग से क्रॉस-प्रोसेस नहीं करता है।