प्रवाह नियंत्रण के बारे में ज्ञान जो हमें पिछले विषय में मिला था, बेशक, महान है, लेकिन अभी भी बहुत सारे सवाल हैं। उदाहरण के लिए: "कैसे होता है-काम करने से पहले?" , "क्या यह सच है कि volatile कैश का एक रीसेट है?" , "किसी भी तरह का मेमोरी मॉडल क्यों था? सब कुछ सामान्य था, कि कुछ शुरू हुआ? "

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

सैद्धांतिक न्यूनतम

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

कैश डिवाइस

"मुख्य मेमोरी" के लिए एक अनुरोध एक महंगा ऑपरेशन है, और आधुनिक मशीनों पर भी सैकड़ों नैनोसेकंड ले सकते हैं। इस समय के दौरान, प्रोसेसर के पास बहुत सारे निर्देशों को पूरा करने का समय हो सकता है। क्रमिक डाउनटाइम के रूप में जीवंतता से बचने के लिए, कैश का उपयोग किया जाता है। सरल शब्दों में, प्रोसेसर मुख्य मेमोरी के अक्सर उपयोग की जाने वाली सामग्री की प्रतियों के बगल में स्टोर करता है। विभिन्न प्रकार के कैश और उनकी पदानुक्रमों के बारे में अधिक जटिल शब्द यहां पाए जा सकते हैं , लेकिन हम इस बात में अधिक रुचि रखते हैं कि कैश में डेटा की प्रासंगिकता की गारंटी कैसे दी जाती है। और अगर एकल प्रोसेसर (या कर्नेल) के मामले में, भविष्य में प्रोसेसर शब्द का उपयोग किया जाएगा), तो जाहिर है, कोई समस्या नहीं है, फिर कई कोर (YAY MULTITHREADING!) के साथ , सवाल पहले ही उठने शुरू हो गए हैं।

प्रोसेसर A यह कैसे जान सकता है कि यदि A ने कैश किया है तो प्रोसेसर B ने कुछ मूल्य बदल दिया है?

या, दूसरे शब्दों में, कैश सुसंगतता कैसे सुनिश्चित करें?

विभिन्न प्रोसेसर के लिए दुनिया की एक सुसंगत तस्वीर होने के लिए, उन्हें किसी तरह से एक दूसरे के साथ संवाद करना होगा। इस संचार में वे जो नियम अपनाते हैं, उन्हें कैश कोहरेंस प्रोटोकॉल कहा जाता है ।

कैश कोहेरेंस प्रोटोकॉल

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

MESI में, कैश में प्रत्येक सेल चार राज्यों में से एक में हो सकता है:

• I nvalid: कैश में कोई मूल्य नहीं
• ई xclusive: मूल्य केवल इस कैश में है, और इसे अभी तक नहीं बदला गया है
• M odized: मान को इस प्रोसेसर द्वारा बदल दिया गया है, और अब तक यह न तो मुख्य मेमोरी में है और न ही किसी अन्य प्रोसेसर के कैश में
• एस घृणा: एक से अधिक प्रोसेसर के कैश में मौजूद मूल्य

राज्य से स्विच करने के लिए, एक संदेश विनिमय होता है, जिसका प्रारूप भी प्रोटोकॉल का हिस्सा है। वैसे, यह विडंबना है कि इतने निचले स्तर पर संदेशों के आदान-प्रदान से राज्यों का परिवर्तन ठीक होता है। समस्या, अभिनेता मॉडल हेटर्स?

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

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

MESI के लिए अनुकूलन और उनके कारण होने वाली समस्याएं

स्टोर बफ़र्स

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

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

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

 void executedOnCpu0() { value = 10; finished = true; } void executedOnCpu1() { while(!finished); assert value == 10; } 

ऐसा लगता है कि क्या गलत हो सकता है? आप जो सोच सकते हैं, उसके विपरीत। उदाहरण के लिए, यदि यह पता चलता है कि कोड के निष्पादन की शुरुआत तक, Cpu0 अनन्य अवस्था में है, और value राज्य में है, उदाहरण के लिए, अमान्य है, तो value बफर finished बाद छोड़ देगा। और यह काफी संभव है कि Cpu1 true रूप में finished जाएगा, और value 10 के बराबर नहीं होगा। इस घटना को रीऑर्डरिंग कहा जाता है। बेशक, केवल इस मामले में ही नहीं होता है। उदाहरण के लिए, संकलक, जो भी कारण से, कुछ निर्देशों को अच्छी तरह से स्वैप कर सकता है।

अमान्य कतारों

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

 void executedOnCpu0() { value = 10; finished = true; } void executedOnCpu1() { while(!finished); assert value == 10; } 

मान लीजिए कि हम भाग्यशाली थे (या हमने कुछ गुप्त ज्ञान का उपयोग किया), और Cpu0 ने मेमोरी कोशिकाओं को उस क्रम में लिखा, जिसकी हमें आवश्यकता थी। क्या यह गारंटी है कि वे उसी क्रम में Cpu1 कैश में आते हैं? जैसा कि आप पहले से ही समझ सकते थे, नहीं। हम यह भी मान लेंगे कि अब एक्सक्लूसिव स्टेट में Cpu1 कैश में value सेल है। क्रियाओं का क्रम फिर निम्नानुसार हो सकता है:

#	Cpu0	Cpu0: मान	CPU0: समाप्त हो गया	CPU1	Cpu1: मान	CPU1: समाप्त हो गया
0	(...)	0 (साझा)	असत्य (अनन्य)	(...)	0 (साझा)	(अमान्य)
1	value = 10; - store_buffer(value) ← invalidate(value)	0 (साझा) (स्टोर बफर में 10)	असत्य (अनन्य)
2				while (!finished); ← read(finished)	0 (साझा)	(अमान्य)
3	finished = true;	0 (साझा) (स्टोर बफर में 10)	सच (संशोधित)
4				→ invalidate(value) ← invalidate_ack(value) - invalidate_queue(value)	0 (साझा) (अमान्य कतार में)	(अमान्य)
5	→ read(finished) ← read_resp(finished)	0 (साझा) (स्टोर बफर में 10)	सच (साझा)
6				→ read_resp(finished)	0 (साझा) (अमान्य कतार में)	सच (साझा)
7				> assert value == 10;	0 (साझा) (अमान्य कतार में)	सच (साझा)
				अभिकथन विफल
एन				- invalidate(value)	(अमान्य)	सच (साझा)

मल्टीथ्रेडिंग सरल और सीधा है, है ना? समस्या चरणों में है (4) - (6)। (4) में invalidate होने के बाद, हम इसे निष्पादित नहीं करते हैं, लेकिन इसे कतार में लिखते हैं। और चरण (6) में हमें read अनुरोध के लिए read_response मिलता है जो पहले (2) की तुलना में भेजा गया था। हालांकि, यह हमें value को अमान्य करने के लिए मजबूर नहीं करता है, और इसलिए जोर पड़ता है। यदि ऑपरेशन (एन) पहले किया गया था, तो हमारे पास अभी भी एक मौका होगा, लेकिन अब इस लानत अनुकूलन ने हमारे लिए सब कुछ तोड़ दिया है! लेकिन दूसरी ओर, वह इतनी तेज़ है और हमें अल्ट्रा-लो-लेटेंसी ™ देती है! यही दुविधा है। लोहे के डेवलपर्स को अग्रिम में पता नहीं चल सकता है कि अनुकूलन का उपयोग कब स्वीकार्य है, और जब यह कुछ तोड़ सकता है। और इसलिए वे इस समस्या को हमारे ऊपर से जोड़ते हैं: “अकेले जाना खतरनाक है। यह लो! ”

हार्डवेयर मेमोरी मॉडल

डेवलपर्स द्वारा आपूर्ति की गई जादूई तलवार जो ड्रेगन से लड़ने के लिए गई थी, वास्तव में तलवार नहीं है, बल्कि खेल के नियम हैं। वे वर्णन करते हैं कि एक प्रोसेसर क्या मूल्यों को देख सकता है जब वह या कोई अन्य प्रोसेसर कुछ क्रियाएं करता है। लेकिन मेमोरी बैरियर पहले से ही तलवार की तरह कुछ और है। MESI उदाहरण में हम विचार कर रहे हैं, ऐसी तलवारें हैं:

स्टोर मेमोरी बैरियर (एसटी, एसएमबी, smp_wmb भी) - एक निर्देश जो प्रोसेसर को उन सभी स्टोर को निष्पादित करने के लिए मजबूर करता है जो इस निर्देश के बाद पालन करने वालों से पहले ही बफर में हैं।

लोड मेमोरी बैरियर (एलडी, आरएमबी, smp_rmb भी) - एक निर्देश जो प्रोसेसर को किसी भी लोड निर्देश को निष्पादित करने से पहले कतार में सभी अमान्य को लागू करने के लिए मजबूर करता है।

हमारे निपटान में नए हथियारों के साथ, हम आसानी से अपने उदाहरण को ठीक कर सकते हैं:

 void executedOnCpu0() { value = 10; storeMemoryBarrier(); finished = true; } void executedOnCpu1() { while(!finished); loadMemoryBarrier(); assert value == 10; } 

महान, सब कुछ काम करता है, हम संतुष्ट हैं! आप शांत, उत्पादक और सही बहु-थ्रेडेड कोड लिख और जा सकते हैं। हालांकि रोक ...

ऐसा लगता है, जावा कहाँ है?

एक बार लिखें @ कहीं भी चलाएं

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

एनबी : यदि यह वाक्यांश आपको भ्रमित करता है, तो जब तक आप क्यों नहीं समझते, तब तक लेख पढ़ना जारी न रखें। और पढ़ें, उदाहरण के लिए, यह ।

सामान्य तौर पर, यह दिलचस्प लगता है। कोई "रीऑर्डरिंग" अवधारणा नहीं है, लेकिन खुद को फिर से व्यवस्थित करना है। अधिकारी स्पष्ट रूप से कुछ छिपा रहे हैं! लेकिन अगर हम आसपास की वास्तविकता के षड्यंत्र के मूल्यांकन को छोड़ देते हैं, तो भी हम जिज्ञासा और जानने की इच्छा के साथ बने रहेंगे। इसे बुझा दो! हमारे हाल के उदाहरण को दर्शाते हुए एक साधारण वर्ग लें: ^{[ github ]}

 public class TestSubject { private volatile boolean finished; private int value = 0; void executedOnCpu0() { value = 10; finished = true; } void executedOnCpu1() { while(!finished); assert value == 10; } } 

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

पिछली बार, हमने दुभाषिया को देखा, जिसका उपयोग वास्तव में उत्पादन में नहीं किया जाता है । इस बार हम देखेंगे कि क्लाइंट कंपाइलर (C1) कैसे काम करता है। मैंने अपने उद्देश्यों के लिए Openjdk-7u40-fcs-src-b43-26_aug_2013 का उपयोग किया।

ऐसे व्यक्ति के लिए, जिसने पहले OpenJDK स्रोत कोड (और साथ ही इसे खोलने वाले के लिए भी नहीं खोला है), यह खोजना एक मुश्किल काम हो सकता है कि उनमें आवश्यक कार्य कहाँ किए जाते हैं। ऐसा करने के सबसे आसान तरीकों में से एक यह है कि बायटेकोड पर गौर करें और वांछित निर्देश का नाम पता करें, और फिर उसे खोजें।

 $ javac TestSubject.java && javap -c TestSubject void executedOnCpu0(); Code: 0: aload_0 //    this 1: bipush 10 //    10 3: putfield #2 //     this (value)    (10) 6: aload_0 //    this 7: iconst_1 //    1 8: putfield #3 //     this (finished)    (1) 11: return void executedOnCpu1(); Code: 0: aload_0 //    this 1: getfield #3 //      this (finished) 4: ifne 10 //    ,     10( ) 7: goto 0 //     10: getstatic #4 //     $assertionsDisabled:Z 13: ifne 33 //  assertions ,    33() 16: aload_0 //    this 17: getfield #2 //      this (value) 20: bipush 10 //    10 22: if_icmpeq 33 //      ,    33() 25: new #5 //   java/lang/AssertionError 28: dup //      29: invokespecial #6 //   ( <init>) 32: athrow //  ,      33: return 

एनबी : बाइटकोड का उपयोग करके रनटाइम में प्रोग्राम के सटीक व्यवहार को निर्धारित करने का प्रयास न करें। JIT कंपाइलर अपना काम करने के बाद, सब कुछ बहुत बदल सकता है।

हम यहां कौन सी दिलचस्प बातें देख सकते हैं? पहली छोटी बात जो बहुत से लोग भूल जाते हैं वह यह है कि दावे डिफ़ॉल्ट रूप से बंद हो जाते हैं। आप उन्हें -ea का उपयोग करके -ea में सक्षम कर सकते हैं। लेकिन यह ऐसा है, बकवास है। getfield और putfield के नाम के लिए हम यहां आए थे। क्या आपको लगता है कि मैं उसी के बारे में बात कर रहा हूं? (बेशक, Gleb! बस कैसे हम बेकन, सवार और दो ब्रा से डायसन क्षेत्र का निर्माण करते हैं ?)

खरगोश के छेद के नीचे

यह देखते हुए कि दोनों क्षेत्रों के लिए समान निर्देशों का उपयोग किया जाता है, आइए देखते हैं कि क्षेत्र में volatile जानकारी कहाँ निहित है। फ़ील्ड डेटा को संग्रहीत करने के लिए वर्ग share/vm/ci/ciField.hpp उपयोग किया जाता है। हम विधि में रुचि रखते हैं

176	bool is_volatile () { return flags().is_volatile(); }

volatile क्षेत्रों तक पहुंचने के लिए सी 1 क्या करता है, यह जानने के लिए, आप इस पद्धति के सभी उपयोगों को पा सकते हैं। कालकोठरी के चारों ओर घूमने और प्राचीन ज्ञान के साथ कई स्क्रॉल इकट्ठा करने के बाद, हम फ़ाइल share/vm/c1/c1_LIRGenerator.cpp में खुद को पाते हैं। जैसा कि उनका नाम हमें संकेत देता है, वह हमारे कोड का एक निम्न-स्तरीय मध्यवर्ती प्रतिनिधित्व ( LIR , निम्न-स्तरीय मध्यवर्ती प्रतिनिधि) उत्पन्न कर रहा है।

उदाहरण के लिए putfield का उपयोग करते हुए C1 मध्यवर्ती प्रतिनिधि

सी 1 में आईआर बनाते समय, हमारे putfield निर्देश को अंततः यहां संसाधित किया जाता है। उन विशेष कार्यों पर विचार करें जो volatile क्षेत्रों के लिए किए जाते हैं और जल्दी से परिचित शब्दों में आते हैं:

1734 1735 1736

if (is_volatile && os::is_MP()) { __ membar_release(); }

यहाँ __ एक मैक्रो है जो gen()->lir()-> फैलता है। और membar_release पद्धति membar_release share/vm/c1/c1_LIR.hpp में परिभाषित किया गया है:

1958	void membar_release() { append(new LIR_Op0(lir_membar_release)); }

वास्तव में, इस लाइन ने हमारे कोड के मध्यवर्ती प्रतिनिधित्व में membar_release स्टेटमेंट जोड़ा है। इसके बाद, निम्नलिखित होता है:

1747 1748 1749

if (is_volatile && !needs_patching) { volatile_field_store(value.result(), address, info); }

volatile_field_store कार्यान्वयन पहले volatile_field_store ही प्लेटफ़ॉर्म पर निर्भर है। उदाहरण के लिए, x86 ( cpu/x86/vm/c1_LIRGenerator_x86.cpp ) पर, क्रियाएं काफी सरल हैं: यह जाँचता है कि क्या फ़ील्ड 64-बिट है, और यदि ऐसा है, तो रिकॉर्डिंग की असमानता की गारंटी देने के लिए ब्लैक मैजिक का उपयोग करें। फिर भी याद रखें कि एक volatile की अनुपस्थिति में volatile टाइप long और double क्षेत्रों को गैर-व्यावहारिक रूप से लिखा जा सकता है ?

और अंत में, बहुत अंत में, एक और मेमोरर रखा गया है, इस बार रिलीज के बिना:

1759 1760 1761	if (is_volatile && os::is_MP()) { __ membar(); }
1956	void membar() { append(new LIR_Op0(lir_membar)); }

नायब : बेशक, मैंने निश्चय ही चल रही कुछ गतिविधियों को छुपाया है। उदाहरण के लिए, जीसी से संबंधित जोड़तोड़। पाठक को एक स्वतंत्र अभ्यास के रूप में अध्ययन करने के लिए आमंत्रित किया जाता है।

IR को असेंबलर में बदलें

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

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

अब हम समझते हैं कि जेवीएम स्थानों में कौन सी झिल्ली होती है। हालांकि, जबकि हमने इसे केवल LIR में देखा था, जो कि निम्न-स्तर, अभी भी मूल कोड नहीं है जो JIT को हमारे लिए उत्पन्न करना चाहिए। वास्तव में C1 कैसे LIR को मूल कोड में परिवर्तित करता है इसका अध्ययन इस लेख के दायरे से परे है, इसलिए आगे की हलचल के बिना, हम सीधे फाइल share/vm/c1/c1_LIRAssembler.cpp । वहां, IR का पूरा रूपांतरण कोड कोड में होता है। उदाहरण के लिए, एक बहुत ही भयावह रेखा में, lir_membar_release माना जाता है:

665 666 667

case lir_membar_release: membar_release(); break;

कहा जाता है कि विधि पहले से ही प्लेटफ़ॉर्म-निर्भर है, और x86 के लिए स्रोत कोड cpu/x86/vm/c1_LIRAssembler_x86.cpp :

3733 3734 3735 3736

void LIR_Assembler::membar_release() { // No x86 machines currently require store fences // __ store_fence(); }

बहुत बढ़िया! एक सख्त मेमोरी मॉडल (टीएसओ-टोटल स्टोर ऑर्डर सहित) के लिए धन्यवाद, इस आर्किटेक्चर पर सभी रिकॉर्ड पहले से ही रिलीज़ शब्दार्थ हैं। लेकिन दूसरे मेम्बर के साथ, सब कुछ थोड़ा और जटिल है:

3723 3724 3725 3726

void LIR_Assembler::membar() { // QQQ sparc TSO uses this, __ membar( Assembler::Membar_mask_bits(Assembler::StoreLoad)); }

यहाँ __ मैक्रो का विस्तार _masm-> , और _masm-> विधि cpu/x86/vm/assembler_x86.hpp में निहित है और इस तरह दिखता है:

1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263

void membar(Membar_mask_bits order_constraint) { if (os::is_MP()) { // We only have to handle StoreLoad if (order_constraint & StoreLoad) { // All usable chips support "locked" instructions which suffice // as barriers, and are much faster than the alternative of // using cpuid instruction. We use here a locked add [esp],0. // This is conveniently otherwise a no-op except for blowing // flags. // Any change to this code may need to revisit other places in // the code where this idiom is used, in particular the // orderAccess code. lock(); addl(Address(rsp, 0), 0);// Assert the lock# signal here } } }

यह पता चला है कि x86 पर हमने प्रत्येक volatile वैरिएबल के रिकॉर्ड पर lock addl $0x0,(%rsp) के रूप में एक महंगी StoreLoad बाधा डाल दी।ऑपरेशन महंगा है क्योंकि यह हमें बफर में सभी स्टोर को निष्पादित करने के लिए मजबूर करता है। हालांकि, यह हमें वही प्रभाव देता है जिसकी हम अपेक्षा करते हैं volatile- अन्य सभी धागे कम से कम उस मूल्य को देखेंगे जो इसके निष्पादन के समय प्रासंगिक था।

यह पता चला है कि x86 पर पढ़ा जाना सबसे आम पढ़ा जाना चाहिए। विधि का एक त्वरित निरीक्षण LIRGenerator::do_LoadFieldहमें बताता है कि पढ़ने के बाद, जैसा कि हमने उम्मीद की थी, membar_acquire सेट है, जो x86 पर इस तरह है:

3728 3729 3730 3731

void LIR_Assembler::membar_acquire() { // No x86 machines currently require load fences // __ load_fence(); }

यह, ज़ाहिर है, इसका मतलब यह नहीं है कि यह volatile readसामान्य की तुलना में किसी भी ओवरहेड को पेश नहीं करता है read। उदाहरण के लिए, भले ही मूल कोड में कुछ भी न जोड़ा गया हो, IR में एक अवरोध की मौजूदगी ही संकलक को कुछ निर्देशों को पुन: व्यवस्थित करने से रोकती है। (अन्यथा आप अजीब कीड़े पकड़ सकते हैं )। अस्थिरता का उपयोग करने के कई अन्य प्रभाव हैं। आप इस बारे में पढ़ सकते हैं, उदाहरण के लिए, इस लेख में ।

जूँ के लिए जाँच करें

PrintAssembly

स्रोत पर बैठना और अनुमान लगाना किसी भी स्वाभिमानी दार्शनिक के लिए एक योग्य व्यवसाय है। हालाँकि, केवल मामले में, हम अभी भी देखते हैं PrintAssembly। ऐसा करने के लिए, लूप में प्रयोगात्मक खरगोश में आवश्यक विधियों में बहुत सारे कॉल जोड़ें, इनलाइनिंग को बंद करें (उत्पन्न कोड में नेविगेट करना आसान बनाने के लिए) और क्लाइंट वीएम में शुरू करें, कथनों को चालू करना न भूलें:

 $ java -client -ea -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly -XX:MaxInlineSize=0 TestSubject ... # {method} 'executedOnCpu0' '()V' in 'TestSubject' ... 0x00007f6d1d07405c: movl $0xa,0xc(%rsi) 0x00007f6d1d074063: movb $0x1,0x10(%rsi) 0x00007f6d1d074067: lock addl $0x0,(%rsp) ;*putfield finished ; - TestSubject::executedOnCpu0@8 (line 15) ... # {method} 'executedOnCpu1' '()V' in 'TestSubject' ... 0x00007f6d1d061126: movzbl 0x10(%rbx),%r11d ;*getfield finished ; - TestSubject::executedOnCpu1@1 (line 19) 0x00007f6d1d06112b: test %r11d,%r11d ... 

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

अस्थिरता के बिना विफलता का प्रदर्शन

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

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

 static class State { int x; int y; // acq/rel var } @Override public void actor1(State s, IntResult2 r) { sx = 1; sx = 2; sy = 1; sx = 3; } @Override public void actor2(State s, IntResult2 r) { r.r1 = sy; r.r2 = sx; } 

हमारे पास दो धागे हैं: एक राज्य बदलता है, और दूसरा राज्य को पढ़ता है और उस परिणाम को बचाता है जो उसने देखा था। फ्रेमवर्क हमारे लिए परिणामों को एकत्रित करता है, और कुछ नियमों के अनुसार उन्हें जांचता है । हम दो परिणामों में रुचि रखते हैं जो दूसरी धारा देख सकते हैं: [1, 0]और [1, 1]। इन मामलों में, हम पढ़ते हैं y == 1, लेकिन एक ही समय में, हमने या तो x( x == 0) में कोई रिकॉर्ड नहीं देखा है, या हमने रिकॉर्डिंग के समय नवीनतम नहीं देखा है y, अर्थात x == 1। हमारे सिद्धांत के अनुसार, ऐसे परिणाम होने चाहिए। इसे जांचें:

 $ java -jar tests-all/target/jcstress.jar -v -t ".*UnfencedAcquireReleaseTest.*" ... Observed state Occurrence Expectation Interpretation [0, 0] 32725135 ACCEPTABLE Before observing releasing write to, any value is OK for $x. [0, 1] 15 ACCEPTABLE Before observing releasing write to, any value is OK for $x. [0, 2] 36 ACCEPTABLE Before observing releasing write to, any value is OK for $x. [0, 3] 10902 ACCEPTABLE Before observing releasing write to, any value is OK for $x. [1, 0] 65960 ACCEPTABLE_INTERESTING Can read the default or old value for $x after $y is observed. [1, 3] 50929785 ACCEPTABLE Can see a released value of $x if $y is observed. [1, 2] 7 ACCEPTABLE Can see a released value of $x if $y is observed. 

यहां हम देख सकते हैं कि 83731840 (लगभग 0.07%) में से 65960 मामलों में हमने देखा y == 1 && x == 0कि स्पष्ट रूप से पुन: हुआ है। हुर्रे, आप टाई कर सकते हैं।

पाठक को अब लेख की शुरुआत में पूछे गए सवालों के जवाब देने के लिए क्या हो रहा है, इसकी अच्छी समझ होनी चाहिए। मुझे आपको याद दिलाना है:

• कैसे होता है-काम से पहले?
• क्या यह सच है कि volatileयह कैश फ्लशिंग है?
• किसी भी तरह का मेमोरी मॉडल क्यों था?

खैर, सब कुछ जगह में गिर गया? यदि नहीं, तो आपको फिर से लेख के उपयुक्त अनुभाग में तल्लीन करने की कोशिश करनी चाहिए। यदि यह मदद नहीं करता है, तो टिप्पणी में आपका स्वागत है!

और एक और बात ©

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

बेशक, सर्वर कंपाइलर (C2) C1 की तुलना में काफी स्मार्ट है, जिसकी हमने जांच की, और इसमें कुछ चीजें बहुत अलग हैं। उदाहरण के लिए, मेमोरी के साथ काम करने का शब्दार्थ पूरी तरह से अलग है।

OpenJDK मल्टीथ्रेडिंग हिम्मत कई स्थानों पर जांच का उपयोग करती हैos::is_MP()यह आपको कुछ ऑपरेशन किए बिना सिंगल-प्रोसेसर मशीनों पर प्रदर्शन में सुधार करने की अनुमति देता है। यदि निषिद्ध कला का उपयोग करने के लिए जेवीएम को लॉन्च करने के लिए सोचने के लिए मजबूर करना है कि यह एक प्रोसेसर पर चलता है, तो यह लंबे समय तक नहीं रहेगा। प्रकाशन से पहले लेख पढ़ने के लिए

बहादुर TheShade , cheremin और artyushov के लिए बहुत धन्यवाद , यह सुनिश्चित करने के लिए कि मैं प्रकाश के बजाय आम लोगों को नहीं लाता, बेवकूफ चुटकुले और ओवरसाइट्स से भरा कुछ बकवास।