आईप्रीम और ओस्ट्रीम साझा स्ट्रीमबफ परस्पर थ्रेड-सुरक्षित डुप्लेक्स I/O के लिए सुरक्षित है?

Question

मैंने buffered नेटवर्क सॉकेट I/O, अंडरफ्लो, ओवरफ़्लो, और सिंक ओवरराइड करने के लिए एक कस्टम स्ट्रीमबफ लिया है ताकि अंडरफ्लो दूसरे दो के सेट के साथ पारस्परिक रूप से थ्रेड-सुरक्षित हो, (मेरे पास अलग इनपुट और आउटपुट आंतरिक बफर हैं) । यह ठीक काम करता है, लेकिन मैं इसे पूर्ण डुप्लेक्स I/O के लिए उपयोग करना चाहता हूं, जहां एक थ्रेड इनपुट कर रहा है, जबकि कोई अन्य आउटपुट कर रहा है, इसलिए मैं नेटवर्क भेजने के दौरान प्राप्त करने के लिए प्राप्त थ्रेड और ओस्ट्रीम के लिए एक आईट्रीम का उपयोग करना चाहता हूं स्ट्रीमबफ के रूप में सभी सॉकेट सामान सार तत्व। मेरा सवाल यह है कि इनपुट और आउटपुट बफर अलग होने पर ओस्ट्रीम पर आउटपुट ऑपरेशंस से प्रभावित स्ट्रीमबफ सदस्यों से इन्सट्रीम विघटन पर इनपुट ऑपरेशंस द्वारा इनपुट ऑपरेशन से प्रभावित कितने हद तक हैं?

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

Answer 1

std::streambuf (या std::basic_streambuf<...>) के लिए कोई विशेष गारंटी नहीं दी गई है जो आमतौर पर दी जाने वाली चीज़ों की तुलना में अधिक गारंटी देता है। यही है, आप किसी भी समय ऑब्जेक्ट की स्थिति को पढ़ने वाले कई धागे प्राप्त कर सकते हैं, लेकिन यदि ऑब्जेक्ट की स्थिति को संशोधित करने वाला एक थ्रेड है तो ऑब्जेक्ट तक पहुंचने वाला कोई अन्य थ्रेड नहीं होगा। दोनों पाठ पढ़ने और लिखने के लिए स्ट्रीम बफर के राज्य को संशोधित करते हैं, यानी औपचारिक दृष्टिकोण से आप बाहरी सिंक्रनाइज़ेशन के बिना उनका उपयोग नहीं कर सकते हैं।

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

संभवतः दो स्ट्रीम बफर के बीच साझा किया जाने वाला एकमात्र संसाधन std::locale ऑब्जेक्ट है जो स्थिर है, हालांकि। इसके अलावा, std::streambuf इस ऑब्जेक्ट का कोई भी उपयोग नहीं करता है: यह आपका स्ट्रीम बफर है जो कुछ पहलुओं का उपयोग कर सकता है (उदा। std::codecvt<...> पहलू)। चूंकि लोकेल को वर्चुअल फ़ंक्शन imbue() पर कॉल के माध्यम से बदला जाता है, इसलिए आप इस परिवर्तन को रोक सकते हैं और यदि आपका स्ट्रीम बफर लोकेल का उपयोग करता है तो जो भी सिंक्रनाइज़ेशन की आवश्यकता होती है।

संक्षेप में, मानक कोई गारंटी नहीं देता है कि यह समान धारा बफर का उपयोग करके पढ़ने और लिखने के लिए समवर्ती धागे का उपयोग करने के लिए काम करेगा।व्यावहारिक रूप से, डीएस 9 के शायद एकमात्र सिस्टम है जहां यह असफल हो जाएगा और साझा किए गए कैश लाइनों में समाप्त होने वाले बफर पॉइंटर्स के कारण दो थ्रेड प्रभावी ढंग से सिंक्रनाइज़ हो सकते हैं।

Answer 2

इनपुट और आउटपुट अनुक्रम अनिवार्य रूप से स्वतंत्र हैं। वहाँ cppreference.com में एक अच्छा चित्र है:

केवल एक चीज इनपुट और आउटपुट दृश्यों के बीच साझा locale वस्तु जो पाठ एन्कोडिंग अनुवाद प्रदर्शन किया codecvt पहलू होता है।

सिद्धांत रूप में, पाठ एन्कोडिंग मध्यरात्रि को बदलना थ्रेड-असुरक्षित होगा, लेकिन व्यवहार में पुस्तकालय किसी भी तरह से उस ऑपरेशन का समर्थन नहीं करते हैं!

आपको जाने के लिए अच्छा होना चाहिए।