अराडने का धागा: जेएसआर -133 के प्यार में कैसे पड़ें। यैंडेक्स रिपोर्ट

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


- मेरा नाम सेवा मिंकोव है। मैं खोज विभाग के क्लाउड इंफ्रास्ट्रक्चर विभाग में काम करता हूं। मैं मुख्य रूप से बैकएंड से निपटता हूं। मैं विभिन्न भाषाओं में लिखता हूं, लेकिन अक्सर यह जावा और जावा वर्चुअल मशीन (जेवीएम) पर चलने वाली भाषाएं होती हैं।

हमारी टीम एक आंतरिक क्लाउड विकसित कर रही है जिसमें लगभग सभी यैंडेक्स सेवाएं लॉन्च की गई हैं - दोनों सार्वजनिक रूप से इस तरह के सर्च, मेल और ऐलिस के साथ-साथ विभिन्न आंतरिक सेवाओं, आभासी मशीनों, साथ ही अल्पकालिक MapReduce कार्यों और मशीन सीखने के कार्यों के रूप में जाना जाता है।

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

और मल्टी-थ्रेडेड प्रोग्रामिंग हमें इसमें बहुत मदद करती है। हम आज उसके बारे में बात करेंगे - यह कहां से आया, यह प्रासंगिक क्यों है; एक मेमोरी मॉडल क्या है, और यह जावा में आम तौर पर कैसे दर्शाया जाता है। हम आपके अनुप्रयोगों का परीक्षण करने और उनकी शुद्धता को सत्यापित करने के कुछ व्यावहारिक पहलुओं पर बात करेंगे।



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

जब से हम अभ्यास कर रहे हैं, हम एक सरल बहु-थ्रेडेड प्रोग्राम लिखने की कोशिश करेंगे और खुद देखेंगे कि यह कैसे काम करता है।



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

एक साधारण जावा कार्यान्वयन कुछ इस तरह दिख सकता है।



हम ReadWriteTest क्लास को लिखेंगे, इसमें दो स्टैटिक वैरिएबल X और Y होंगे। मुख्य रूप से सीधे, हम दो थ्रेड्स Thread1 और Thread2 का निर्माण करते हैं, उनमें से प्रत्येक को कुछ लैंबडा फंक्शन देते हैं, जो उस समय निष्पादित होता है जब थ्रेड निष्पादित होता है। कोड को पिछली स्लाइड से वहां रखें और दो धागे शुरू करें।

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

^{_{स्लाइड से लिंक करें}}

पहिया को सुदृढ़ नहीं करने के लिए, हम एक तैयार किए गए उपकरण का उपयोग कर सकते हैं। इसे jcstress कहा जाता है, Java Concurrency तनाव उपयोगिता का परीक्षण करता है जो OpenJDK परियोजना का हिस्सा है।

यह उपयोगिता तनाव परीक्षण लिखने के लिए कुछ रूपरेखा प्रदान करती है। इस मामले में, पिछली स्लाइड से कोड काफी आसानी से फिर से लिखा गया है। सबसे पहले, हम jcstress Test एनोटेशन को कक्षा में लटकाएंगे, जो उपयोगिता की दृष्टि से हमारी टेस्ट स्क्रिप्ट को सरल बनाता है। हम इसे राज्य वर्ग के साथ भी चिह्नित करते हैं, जो कहता है कि वर्ग में डेटा है जो बदल सकता है: दोनों को संशोधित किया जा रहा है और विभिन्न धाराओं से पढ़ा जा सकता है। हम दो विधियों, थ्रेड 1 और थ्रेड 2 की घोषणा करते हैं, और उन्हें अभिनेता एनोटेशन के साथ चिह्नित करते हैं। अभिनेता एनोटेशन का अर्थ है कि विधि को एक अलग थ्रेड में निष्पादित किया जाना चाहिए। jcstress गारंटी देता है कि राज्य वर्ग के ठीक एक उदाहरण पर इस तरह की प्रत्येक विधि को एक अलग थ्रेड में निष्पादित किया जाएगा। जिस क्रम में उन्हें लॉन्च किया जाएगा वह विशेष रूप से निर्दिष्ट नहीं है। और परिणाम स्लाइड पर दिखाए गए कुछ II_Result ऑब्जेक्ट को लिखा जाएगा। हम मान सकते हैं कि यह दो संख्यात्मक मूल्यों का एक टपल है, जो सिर्फ डिपेंडेंसी इंजेक्शन पद्धति द्वारा प्रस्तुत किया जाता है, जिसके बारे में किरिल ने पिछली रिपोर्ट में बात की थी।

इस परीक्षण को शुरू करने से पहले, आइए इस बारे में विचार करें कि कमांड्स क्या निष्कर्ष दे सकते हैं और आर 1 और आर 2 में हम किन मूल्यों को जोड़ सकते हैं।



ऐसा करने के लिए, हम तथाकथित वैकल्पिक मॉडल का उपयोग करते हैं। एक तरीका या दूसरा, प्रत्येक ऑपरेशन: पढ़ना या लिखना, किसी क्रम में किया जाता है। यह केवल इन सभी विकल्पों से गुजरने के लिए पर्याप्त है और देखें कि हमारे पास क्या परिणाम होंगे।



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

पहला उत्तर शून्य-एक है।



घटनाओं के विकास का दूसरा प्रकार इसके विपरीत है: धारा दो को धारा एक के आगे निष्पादित किया गया था।



तदनुसार, हमें एक-शून्य का दर्पण परिणाम मिलता है।



लगभग चार और विकल्प हैं जो एक ही परिणाम देते हैं जब हमारे पास थ्रेड थ्रेड निष्पादन पूरी तरह से भ्रमित होता है। उदाहरण के लिए, हमने X में एक स्ट्रीम में एक यूनिट रिकॉर्ड की, दूसरे में हम Y में एक यूनिट रखने में कामयाब रहे, और हम एक-एक की गणना करते हैं। फिर आप देख सकते हैं कि घरेलू व्यायाम के रूप में अन्य विकल्प क्या हैं।



ऐसा लगता है कि हम सभी संभावित विकल्पों पर चले गए, और कुछ भी नहीं है। आइए उपयोगिता को चलाएं और देखें कि यह क्या निष्कर्ष देता है।

^{_{स्लाइड से लिंक करें}}

आउटपुट तालिका की तरह दिखता है। पहला कॉलम उन परिणामों को सूचीबद्ध करता है जो हमने II_Result में जोड़े थे - उपयोगिता इस कोड को लाखों बार चलाती है - और उन मामलों की संख्या जब किसी विशेष परिणाम का सामना करना पड़ा था। लेकिन शायद यह रिपोर्ट नहीं होती अगर सब कुछ इतना सरल होता।

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

आइए विचार करें कि यह क्यों हुआ और हम इसके साथ कैसे रह सकते हैं। मैं आपको इस तथ्य पर ध्यान देने के लिए भी कहता हूं कि विशेष रूप से मेरी मशीन पर एक-एक विकल्प विशेष रूप से पाया गया था। 130 मिलियन प्रदर्शनों में से, केवल 154 प्रदर्शनों में से एक का परिणाम हुआ। और इसके विपरीत, लगभग 30% मामलों में शून्य-शून्य बहुत बार होता है।



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

उदाहरण के लिए, हम लोहे के कुछ "सापेक्ष प्रभाव" देख सकते हैं। यह निम्न नस में सोचा जा सकता है: 3-गीगाहर्ट्ज प्रोसेसर के एक घड़ी चक्र में, प्रकाश एक वैक्यूम में लगभग 10 सेमी की यात्रा करता है। प्रोसेसर की मेमोरी को पढ़ने और लिखने के लिए प्रोटोकॉल जटिल है और कभी-कभी मूल्य को एक कोर से दूसरे में स्थानांतरित करने के लिए कई सैकड़ों घड़ी चक्र लगते हैं। तदनुसार, एक कोर अतीत को देखने के लिए लग सकता है। रिकॉर्ड होने के बाद परिणाम, लेकिन हम पुराने मूल्य देखते हैं। इसके अलावा, प्रोसेसर भी स्थिर नहीं रहते हैं और स्थानों में निर्देश बदल सकते हैं।

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

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

यह चीजों को बहुत जटिल बनाता है: यह समझना मुश्किल है कि कार्यक्रम क्या करता है, और इसे परीक्षण करना मुश्किल है।

परीक्षण की जटिलता के बारे में, हम यह जोड़ सकते हैं कि एक ही परिणाम 130 मिलियन कॉल में से 154 गुना पाया गया। इस परिणाम की घटना की संभावना एक मिलियन है। उत्पादन में, इसका मतलब है कि इस तरह के बग को हफ्तों के बाद पुन: पेश किया जा सकता है। और यह निश्चित रूप से रविवार की रात को कहीं होगा, जब आपको यह उम्मीद नहीं थी।



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



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

मेमोरी मॉडल इस अमूर्त मशीन में एक केंद्रीय स्थान रखता है। उसे एक प्रश्न का उत्तर देना चाहिए: यदि मैं किसी स्ट्रीम में एक चर X को पढ़ता हूं, तो मैं वहां कौन सी अंतिम प्रविष्टियों का परिणाम देख सकता हूं? मेमोरी मॉडल को औपचारिक रूप देने का प्रयास पहली बार जावा भाषा में किया गया था, अन्य सभी मेमोरी मॉडल बाद में दिखाई दिए। मान लीजिए कि C ++ 11 कुछ परिवर्तनों के साथ जावा मेमोरी मॉडल का लगभग कॉपी पेस्ट है।

जावा में कई मेमोरी मॉडल थे। प्रारंभ में, तथाकथित "घंटी के आकार का" मेमोरी मॉडल, इसे असफल के रूप में मान्यता दी गई थी, क्योंकि इसने प्रोग्रामर के काम को बाधित किया था जो जावा में लिखते हैं, और संकलक के लिए कुछ अनुकूलन को मना करते हैं, जो अपने लिए काफी उपयुक्त हैं। तदनुसार, सामुदायिक प्रक्रिया JSR-133 के भाग के रूप में, एक आधुनिक मेमोरी मॉडल लिखा गया था।

चूँकि हमारे पास एक विनिर्देश के रूप में शास्त्र है, आइए हम इस पर गौर करने और समझने की कोशिश करें कि वास्तव में अंदर क्या चल रहा है।



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

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

यह इतना जटिल क्यों है? मैं गलत रास्ते पर चला गया और मैंने आपको मेरी तरह काम करने के लिए बहुत चेतावनी दी।

मैंने इसे लिया, इंटरनेट पर देखा कि एक मेमोरी मॉडल क्या है। कंपाइलर राइटर्स के लिए JSR-133 कुकबुक नामक पुस्तक मिली। वह बताती है कि कैसे एक कंपाइलर डेवलपर इस मेमोरी मॉडल को सरल तरीके से लागू कर सकता है। समस्या यह है कि यह एक विशिष्ट कार्यान्वयन है, और इसका उपयोग संपूर्ण मेमोरी मॉडल को सामान्य रूप से आंकने के लिए नहीं किया जा सकता है।

वैसे भी, मुख्य निष्कर्ष पर एक छोटा सा प्रयास करने का प्रयास करें जिसे जावा मेमोरी मॉडल से समझा जा सकता है।



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

दूसरे, कहीं से ली गई पतली हवा के तथाकथित तथाकथित भाषा में निषिद्ध हैं। दुर्भाग्य से, हमारे पास इसे दिखाने का समय नहीं है, लेकिन ऐसे मामले हैं जब कंपाइलर वास्तव में ऐसा रूपांतरण कर सकता है कि एकल-थ्रेडेड प्रोग्राम में सब कुछ सही होगा, और आपके पास एक बहु-थ्रेडेड प्रोग्राम में रिकॉर्ड हो सकता है जो आपने नहीं किया था।

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



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

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

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



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

हम एक सूत्र में घटित होने से पहले व्यवस्था करेंगे। X से लिखना Y से और दूसरे धागे में पढ़ने से पहले होता है। Y से लिखना X से पढ़ने से पहले होता है।

और फिर हमारे पास चार सिंक्रनाइज़ेशन क्रियाएं हैं: एक्स को लिखना, वाई को लिखना, एक्स से पढ़ना, वाई से पढ़ना। वे कुछ क्रम में दिखाई दे सकते हैं, और एक जोड़ी दो मामलों में हो सकती है।



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



दूसरा मामला तब होता है जब एक कनेक्शन उत्पन्न होता है। यह वही है - वाई से लिखना होता है- वाई से पढ़ने से पहले। इसके अलावा एक्स के बीच कोई संबंध नहीं है। तदनुसार, परिणाम समान है, केवल वहां आपको एक-शून्य, शून्य-एक मिलता है। सैद्धांतिक रूप से, हम अपने नए कार्यक्रम व्यवहार को साबित कर सकते हैं।



आप इसे व्यवहार में देख सकते हैं। हमारे परीक्षण में अस्थिर कीवर्ड जोड़ें और जोड़ें। भागो और देखो, वास्तव में, हमारे देश में इस मूल्य को कभी भी पुन: पेश नहीं किया जाएगा। happens-before — . .



, . volatile Z volatile, . , Z; , , , Z. happens-before . , Z , . .

, , — put value. — get value . happens-before , , put value happens-before get value. , happens-before , volatile, . , , — put happens-before get.



, . -, . , , . , . , , . , . , , , , .

-, , jcstress. : , JVM . , .

, . — «The Art of Multiprocessor Programming» . , happens-before, , . . — «Java Concurrency in Practice» . , . , , . . . , performance- Oracle, Red Hat. , Java- , . JMM.

. , -, . , , YouTube. , , . .