मेमोरी बैरियर की अनुपस्थिति में प्रोग्राम क्रैश का प्रदर्शन

जेफ प्रेशिंग ने एक उत्कृष्ट प्रदर्शन पोस्ट किया कि कैसे सामान्य सी ++ कोड मल्टी-कोर प्रोसेसर पर अप्रत्याशित रूप से खराब किए गए अनुरोध कतारबद्ध (कमजोर-ऑर्डर किए गए सीपीयू), यानी एआरएम प्रोसेसर पर रिटर्न देता है। उदाहरण के लिए, एक iPhone या कुछ आधुनिक एंड्रॉइड डिवाइस पर।

दो थ्रेड 20,000,000 बार के साथ एक साधारण सी ++ प्रोग्राम म्यूटेक्स द्वारा संरक्षित मूल्य में एक जोड़ता है - और हर बार आउटपुट एक अलग परिणाम उत्पन्न करता है, जो 20,000,000 से कम है!



जैसा कि कहा जाता है, हमारा दुश्मन सीपीयू है ।

अपने ब्लॉग पर, जेफ प्रेशिंग ने लॉक-फ्री प्रोग्रामिंग, नॉन-ब्लॉकिंग थ्रेड सिंक्रोनाइज़ेशन तकनीकों पर कई लेख प्रकाशित किए हैं। जिसमें उन्होंने डबल चेक लॉक के उपयोग और मेमोरी बैरियर लगाने की आवश्यकता के बारे में बहुत कुछ बताया। जेफ ने अब फैसला किया कि एक प्रदर्शन एक हजार शब्दों से बेहतर था।

डेमो प्रोग्राम का कोड , जिसमें दोनों धाराओं में से प्रत्येक sharedValue को sharedValue के साझा मूल्य में sharedValue , म्यूटेक्स द्वारा संरक्षित है।

यहां एक मेशिफ्ट म्यूटेक्स जैसा दिखता है: एक साधारण सीमफोर जो 1 मान लेता है यदि यह व्यस्त है, या 0 यदि यह मुफ़्त है।

 int expected = 0; if (flag.compare_exchange_strong(expected, 1, memory_order_acquire)) { // The lock succeeded } 

तर्कों का उपयोग करना memory_order_acquire और memory_order_release कुछ के लिए बेमानी लग सकता है, लेकिन यह एक आवश्यक गारंटी है कि कुछ सूत्र एक समन्वित तरीके से सेमाफोर मान का समन्वय करते हैं।

 flag.store(0, memory_order_release); 

अपने कार्यक्रम में, जेफ़ ने जानबूझकर memory_order_acquire और memory_order_release को हटा दिया ताकि यह प्रदर्शित हो सके कि इससे क्या हो सकता है:

 void IncrementSharedValue10000000Times(RandomDelay& randomDelay) { int count = 0; while (count < 10000000) { randomDelay.doBusyWork(); int expected = 0; if (flag.compare_exchange_strong(expected, 1, memory_order_relaxed)) { // Lock was successful sharedValue++; flag.store(0, memory_order_relaxed); count++; } } } 

यह वही है जो Xcode उत्पन्न करता है।



IPhone पर प्रोग्राम चलाने का परिणाम पहले ही दिखाया जा चुका है।



ऐसा क्यों हो रहा है? तथ्य यह है कि कमजोर ऑर्डर वाले प्रोसेसर (कमजोर-ऑर्डर वाले सीपीयू) अनुरोध कतार को अनुकूलित कर सकते हैं, जिससे आपके निर्देशों को उस क्रम में निष्पादित नहीं किया जाएगा जिसमें आपने सोचा था। उदाहरण के लिए, आरेख दिखाता है कि कैसे अलग-अलग सीपीयू पर उपरोक्त उदाहरण से दो धागे sharedValue मान को बदलने के लिए एक सामान्य म्यूटेक्स का उपयोग करते हैं।



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

क्यों सीपीयू अनुरोध पंक्ति को फिर से जारी करता है एक और लेख के लिए एक विषय है। इससे निपटने के लिए, आपको मेमोरी बाधाओं को स्थापित करने की आवश्यकता है जो पड़ोसी निर्देशों के एक जोड़े को साझा करते हैं और सुनिश्चित करते हैं कि वे स्थानों को स्विच नहीं करते हैं। यह वह है जो memory_order_acquire और memory_order_release तर्कों के लिए है। हम उन्हें उनके स्थान पर लौटाते हैं।

 void IncrementSharedValue10000000Times(RandomDelay& randomDelay) { int count = 0; while (count < 10000000) { randomDelay.doBusyWork(); int expected = 0; if (flag.compare_exchange_strong(expected, 1, memory_order_acquire)) { // Lock was successful sharedValue++; flag.store(0, memory_order_release); count++; } } } 

इस मामले में संकलक dmb ish निर्देश सम्मिलित करता है जो ARMv7 में मेमोरी बैरियर के रूप में काम करता है।



और फिर म्यूटेक्स पहले से ही सामान्य रूप से अपना काम करना शुरू कर रहा है और मज़बूती से sharedValue सामान्य मूल्य की रक्षा कर रहा है।



अब हमें कमजोर-ऑर्डर वाले प्रोसेसर के बड़े पैमाने पर उपयोग का सामना करना पड़ रहा है। पहले, वे केवल सर्वर या अतीत के उच्च-प्रदर्शन "पॉपपीज़" में उपयोग किए जाते थे, जहां मल्टी-कोर पावरपीसी थे। अब मल्टी-कोर एआरएम - हर मोबाइल फोन में। इसलिए मोबाइल एप्लिकेशन विकसित करते समय इस बारीकियों को ध्यान में रखा जाना चाहिए।

"विशेष रूप से छोटी गाड़ी" प्रस्तुत करने वाले कोड में, त्रुटि की संभावना 1 से 1000 है, और एक नियमित कार्यक्रम में यह 1 से 1.000.000 होगा, अर्थात्, इस तरह के ग्लिच परीक्षण के दौरान पकड़ना बेहद मुश्किल है। कार्यक्रम पूरी तरह से 999.999 बार चल सकता है, और अगली बार यह दुर्घटनाग्रस्त हो जाता है।