👵🏾 🚴🏾 ☘️ बूस्ट :: संदेश की गति और देरी के लिए लॉकफ्री टेस्ट ➰ 🥔 ☀️

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

परिचय: गैर-अवरुद्ध डेटा संरचनाएं और एल्गोरिदम क्या हैं

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

यहाँ एक सरल उदाहरण है:

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

आप हर्ब सटर के साक्षात्कार बयान में अधिक पढ़ सकते हैं, वह थोड़ा अलग संदर्भ में है, लेकिन वह इस समस्या पर बहुत ही संयम से चर्चा करता है। यह सहज रूप से लगता है कि गति और विलंबता की अवधारणाएं समान हैं - पहला बड़ा, दूसरा छोटा। हालांकि, एक करीब से पता चलता है कि वे स्वतंत्र और यहां तक कि सहसंबद्ध हैं।
गैर-अवरुद्ध संरचनाओं के साथ इसका क्या करना है? सबसे सीधी बात यह है कि विलंबता के लिए, प्रवाह को धीमा करने या रोकने का कोई भी प्रयास घातक है। धारा को सुव्यवस्थित करना आसान है, लेकिन इसे जगाना असंभव है। उनकी ~~स्नेही चुंबन~~ ऑपरेटिंग सिस्टम के कर्नेल जगा सकते हैं और यह समय पर ~~और दोपहर के भोजन के लिए टूट के साथ~~ ऐसा नहीं करता ~~है।~~ किसी को यह समझाने की कोशिश करें कि आपका कार्यक्रम उन लोगों के लिए प्रतिबद्ध है। 200 नैनोसेकेंड के भीतर प्रतिक्रिया करने का कार्य, इस समय 10 मिलीसेकंड (* निक्स सिस्टम के लिए विशिष्ट समय) के लिए सो गया और इसे परेशान नहीं करना बेहतर है। लॉक-फ्री डेटा संरचनाएं बचाव के लिए आती हैं, जिन्हें अन्य धाराओं के साथ सिंक्रनाइज़ेशन के लिए स्ट्रीम को रोकने की आवश्यकता नहीं होती है।
हम ऐसी एक संरचना के बारे में बात करेंगे।

मंच के लिए पहला दृष्टिकोण

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

 बढ़ावा देना :: lockfree :: कतार lockfree है
 40,000,000 वस्तुओं का उत्पादन किया।
 40,000,000 वस्तुओं का उपभोग किया।

 असली 0m15.332s
 उपयोगकर्ता 1m0.376s
 sys 0m0.064s

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

यहाँ, कृपया, यह काफी उचित लग रहा है। एक्स अक्ष पर, संचरित संदेशों की संख्या से विभाजित नैनोसेकंड में कुल निष्पादन समय, वाई अक्ष पर ऐसी घटनाओं की संख्या है।

और यहाँ विभिन्न लेखकों / पाठकों के लिए परिणाम है:

यहाँ, सब कुछ इतना रसीला नहीं है, वितरण के किसी भी व्यापककरण से पता चलता है कि कुछ भी बेहतर तरीके से काम नहीं कर रहा है। इस मामले में, यह बहुत स्पष्ट है कि इस परीक्षण में पढ़ने वाली धाराएं कभी भी नियंत्रण नहीं छोड़ती हैं और जब उनकी संख्या कोर की संख्या तक पहुंचती है, तो सिस्टम को उन्हें निलंबित करना होगा।

मंच के लिए दूसरा दृष्टिकोण

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

 सूत्र: 1 लिखना, 1 पढ़ना
 विफल: 0 धक्का, 3267 चबूतरे
 बैंडविड्थ: 177.864 एनएस
 विलंबता: 1.03614e + 08 एनएस

अब हम कतार से संदेश को पढ़ने के लिए और कतार में लिखने के असफल प्रयासों की संख्या भी गिनते हैं (पहला पाठ्यक्रम यहाँ हमेशा शून्य होगा, यह एक आवंटन विकल्प है)।
हालाँकि, यह और क्या है? देरी, जिसे हमने सहज रूप से एक ही आदेश मान लिया - 200 एनएस, अचानक 100 मिलीसेकंड से अधिक हो जाता है, आधा मिलियन गुना अधिक! यह सिर्फ नहीं हो सकता।
लेकिन आखिरकार, अब हम प्रत्येक संदेश की देरी को जानते हैं, अब दबाएं और देखें कि यह वास्तविक समय में कैसा दिखता है, यहां कई समान परिणाम शुरू होते हैं, ताकि आप देख सकें कि प्रक्रिया कितनी यादृच्छिक है:

यदि हम एक बार में एक स्ट्रीम लिखते हैं और पढ़ते हैं, और यदि चार, तो यहाँ:

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

लाल रेखा देरी के बिना प्रारंभिक परीक्षण है, हरी रेखा देरी के साथ है।
यह पूरी तरह से अलग मामला है, अब आप आँकड़ों की गणना कर सकते हैं।

यहाँ लिखने और पढ़ने की संख्या के कई संयोजनों का परिणाम है, एक्स में स्वीकार्य पैमाने बनाए रखने के लिए, सबसे बड़े नमूनों में से 1% को छोड़ दिया गया है:

ध्यान दें कि विलंबता 300 ns के भीतर आत्मविश्वास से रहती है और केवल वितरण पूंछ आगे और आगे बढ़ती है।

और यहाँ क्रमशः एक और चार लेखन धाराओं के लिए परिणाम हैं।

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

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

निश्चित क्षमता कतार के बारे में क्या?

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

लाल ग्राफ 128 बाइट्स से मेल खाता है, उदाहरण में उपयोग किया गया है, हरे रंग का अधिकतम 65534 बाइट्स से मेल खाता है।

वैसे

प्रलेखन का कहना है कि अधिकतम आकार 65535 बाइट्स है - यह विश्वास न करें, एक कोर डंप प्राप्त करें

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

दो समूहों में इस तरह के स्पष्ट अलगाव को देखना थोड़ा अप्रत्याशित था, जहां पाठकों की गति लेखकों की गति से अधिक हो जाती है, हमें हमारे वांछित सैकड़ों नैनोसेकंड मिलते हैं, जहां इसके विपरीत, यह 30-40 माइक्रोसेकंड तक बढ़ जाता है, ऐसा लगता है कि यह मेरी मशीन पर संदर्भ को बदलने का समय है। यह 128-बाइट बफर के लिए परिणाम है, 64K के लिए यह बहुत समान दिखता है, केवल दाहिने हाथ समूह रेंगना, अब तक, दसियों मिलीसेकंड तक।
यह अच्छा है या बुरा? यह कार्य पर निर्भर करता है, एक तरफ, हम आत्मविश्वास से गारंटी दे सकते हैं कि देरी किसी भी परिस्थिति में 40 μs से अधिक नहीं होगी, और यह अच्छा है; दूसरी ओर, अगर हमें इस मूल्य से कम कुछ अधिकतम विलंब की गारंटी देने की आवश्यकता है, तो हमारे पास एक कठिन समय होगा। पाठकों / लेखकों के संतुलन में कोई भी बदलाव, उदाहरण के लिए, संदेश प्रसंस्करण में थोड़े बदलाव के कारण देरी में अचानक परिवर्तन हो सकता है।

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

यह पहले से ही काफी अच्छा है, दोनों समूह पूरी तरह से विलय नहीं हुए, लेकिन सही एक ने संपर्क किया ताकि अधिकतम विलंबता 600 से अधिक न हो। इसके लिए मेरा शब्द लें, बड़े बफर के लिए आंकड़े 64K हैं, यह बिल्कुल समान दिखता है, मामूली अंतर नहीं।

यह एक निष्कर्ष पर जाने का समय है

मुझे आशा है कि जिन लोगों के पास अनुभव है वे परीक्षण के परिणामों से कुछ उपयोगी खुद को निकालने में सक्षम होंगे। यहाँ मैं खुद सोचता हूँ:

यदि आप केवल गति में रुचि रखते हैं, तो सभी विकल्प लगभग बराबर हैं और प्रति संदेश सैकड़ों नैनोसेकंड के क्रम का औसत समय देते हैं। इस मामले में, फिक्स्ड_कैपेसिटी कतार अधिक हल्की होती है, क्योंकि इसमें निश्चित मात्रा में मेमोरी होती है। हालाँकि, अनुप्रयोग हैं, एक लकड़हारा, उदाहरण के लिए, जहां यह संभव है कि रीडिंग स्ट्रीम को जितनी जल्दी हो सके "नि: शुल्क" करना महत्वपूर्ण है, इस मामले में आवंटन कतार बेहतर है, दूसरी ओर, यह असीमित रूप से मेमोरी का उपभोग कर सकता है।
यदि विलंबता को कम करने की आवश्यकता होती है, तो प्रत्येक संदेश का प्रसंस्करण समय अलग-अलग होता है, स्थिति जटिल होती है। उन अनुप्रयोगों के लिए जहां आप लेखन स्ट्रीम (लॉगर्स) को ब्लॉक नहीं करना चाहते हैं, यह निश्चित रूप से एक आवंटन विकल्प चुनने के लायक है। सीमित मेमोरी के मामले में, फिक्स्ड_कैपिटी विशिष्ट रूप से उपयुक्त है, सिग्नल के आंकड़ों के आधार पर बफर आकारों का चयन करना होगा।
किसी भी मामले में, एल्गोरिथ्म डेटा स्ट्रीम की तीव्रता के संबंध में अस्थिर है। जब एक निश्चित महत्वपूर्ण सीमा पार हो जाती है, तो देरी परिमाण के कई आदेशों से कूद जाती है और वास्तव में लाइन (लेकिन औपचारिक रूप से नहीं) अवरुद्ध हो जाती है। एक नियम के रूप में, अवरुद्ध मोड में गिरने के बिना सिस्टम को काम करने के लिए ठीक-ट्यूनिंग की आवश्यकता होती है।
इनपुट और आउटपुट स्ट्रीम का एक पूर्ण डिकूपिंग केवल आवंटित संस्करण में संभव है, यह हासिल किया गया है, हालांकि, अनियंत्रित मेमोरी की खपत और अनियंत्रित लंबी देरी के कारण।
Fixed_capacity आपको कुछ उचित सीमा तक अधिकतम विलंबता को सीमित करते हुए तेजी से डेटा हस्तांतरण प्राप्त करने की अनुमति देता है। फिक्स्ड_कैपेसिटी कतार स्वयं अनिवार्य रूप से एक बहुत ही हल्की संरचना है। मुख्य ऋण यह है कि यदि किसी कारण से पाठक सामना नहीं कर सकते हैं या फ्रीज़ नहीं कर रहे हैं तो लेखन धाराएँ अवरुद्ध हो जाती हैं। बफर के बड़े आकार, मेरी राय में, शायद ही कभी आवश्यक हैं, वे आपको संक्रमणकालीन गतिशीलता को प्राप्त करने की अनुमति देते हैं, आवंटन कतार के करीब कुछ।
मेरे लिए एक बहुत ही अप्रिय आश्चर्य गतिकी पर लगातार काम कर रहे बेकार पढ़ने की धाराओं का महान नकारात्मक प्रभाव था। यहां तक कि मामले में जब थ्रेड्स की कुल संख्या <= सीपीयू, 100% खपत करने वाले एक और धागे को जोड़ने से सुधार नहीं होता है, लेकिन गतिशीलता खराब हो जाती है। ऐसा लगता है कि "बड़े सर्वर" की रणनीति, जब प्रत्येक महत्वपूर्ण धागा को एक अलग कोर सौंपा जाता है, हमेशा काम नहीं करता है।
इस संबंध में, एक का उल्लेख नहीं किया गया है और अभी भी हल नहीं हुई समस्या यह है कि किसी घटना के इंतजार में कुशलता से धागे का उपयोग कैसे किया जाए। यदि आप इसे सोने के लिए डालते हैं - विलंबता ~~कर्म~~ वसा को खराब कर देता है, यदि इसका उपयोग अन्य कार्यों के लिए किया जाता है - समस्या जल्दी से कार्य से स्विच करने तक उत्पन्न होती है। मुझे लगता है कि आदर्श के लिए एक अच्छा सन्निकटन यह सुनिश्चित करने के लिए एक धारा को बढ़ावा देने के लिए संभव होगा :: io_service, ताकि कुशलता से कम से कम दुर्लभ घटनाओं की सेवा करने के लिए। मुझे यह सुनकर खुशी होगी कि किसी के पास कोई विचार है।

उन लोगों के लिए जिन्हें एक कोड की आवश्यकता है

#include <boost/thread/thread.hpp> #include <boost/lockfree/queue.hpp> #include <time.h> #include <atomic> #include <iostream> std::atomic<int> producer_count(0); std::atomic<int> consumer_count(0); std::atomic<unsigned long> push_fail_count(0); std::atomic<unsigned long> pop_fail_count(0); #if 1 boost::lockfree::queue<timespec, boost::lockfree::fixed_sized<true>> queue(65534); #else boost::lockfree::queue<timespec, boost::lockfree::fixed_sized<false>> queue(128); #endif unsigned stat_size=0, delay=0; std::atomic<unsigned long>* stat=0; std::atomic<int> idx(0); void producer(unsigned iterations) { timespec t; for (int i=0; i != iterations; ++i) { ++producer_count; clock_gettime(CLOCK_MONOTONIC, &t); while (!queue.push(t)) ++push_fail_count; if(delay) usleep(0); } } boost::atomic<bool> done (false); void consumer(unsigned iterations) { timespec t, v; while (!done) { while (queue.pop(t)) { ++consumer_count; clock_gettime(CLOCK_MONOTONIC, &v); unsigned i=idx++; v.tv_sec-=t.tv_sec; v.tv_nsec-=t.tv_nsec; stat[i]=v.tv_sec*1000000000+v.tv_nsec; } ++pop_fail_count; } while (queue.pop(t)) { ++consumer_count; clock_gettime(CLOCK_MONOTONIC, &v); unsigned i=idx++; v.tv_sec-=t.tv_sec; v.tv_nsec-=t.tv_nsec; stat[i]=v.tv_sec*1000000000+v.tv_nsec; } } int main(int argc, char* argv[]) { boost::thread_group producer_threads, consumer_threads; int indexed=0, quiet=0; int producer_thread=1, consumer_thread=1; int opt; while((opt=getopt(argc,argv,"idqr:w:")) !=-1) switch(opt) { case 'r': consumer_thread=atol(optarg); break; case 'w': producer_thread=atol(optarg); break; case 'd': delay=1; break; case 'i': indexed=1; break; case 'q': quiet=1; break; default : return 1; } int iterations=6000000/producer_thread/consumer_thread; unsigned stat_size=iterations*producer_thread*consumer_thread; stat=new std::atomic<unsigned long>[stat_size]; timespec st, fn; clock_gettime(CLOCK_MONOTONIC, &st); for (int i=0; i != producer_thread; ++i) producer_threads.create_thread([=](){ producer(stat_size/producer_thread); }); for (int i=0; i != consumer_thread; ++i) consumer_threads.create_thread([=]() { consumer(stat_size/consumer_thread); }); producer_threads.join_all(); done=true; consumer_threads.join_all(); clock_gettime(CLOCK_MONOTONIC, &fn); std::cerr << "threads : " << producer_thread <<" write, " << consumer_thread << " read" << std::endl; std::cerr << "failed : " << push_fail_count << " pushes, " << pop_fail_count << " pops" << std::endl; fn.tv_sec-=st.tv_sec; fn.tv_nsec-=st.tv_nsec; std::cerr << "bandwidth: " << (fn.tv_sec*1e9+fn.tv_nsec)/stat_size << " ns"<< std::endl; double ct=0; for(auto i=0; i < stat_size; ++i) ct+=stat[i]; std::cerr << "latency : "<< ct/stat_size << " ns"<< std::endl; if(!quiet) { if(indexed) for(auto i=0; i < stat_size; ++i) std::cout<<i<<" "<<stat[i]<<std::endl; else for(auto i=0; i < stat_size; ++i) std::cout<<stat[i]<<std::endl; } return 0; }

बूस्ट :: संदेश की गति और देरी के लिए लॉकफ्री टेस्ट

परिचय: गैर-अवरुद्ध डेटा संरचनाएं और एल्गोरिदम क्या हैं

मंच के लिए पहला दृष्टिकोण

मंच के लिए दूसरा दृष्टिकोण

निश्चित क्षमता कतार के बारे में क्या?

यह एक निष्कर्ष पर जाने का समय है

More articles: