अगर मैं एक धागा लगातार getV आह्वान किया है और मैं सिर्फ में एक बार setV एक और धागा करते हैं, पढ़ने धागा सही लेखन के बाद नया मान देखने के लिए गारंटी है कि है
नहीं, पढ़ने धागा सिर्फ अपनी एक प्रतिलिपि v
के मूल्य का, और इस तरह नवीनतम मूल्य नहीं मिल (सीपीयू कोर जो पढ़ने धागा पर चल रहा है द्वारा स्वचालित रूप से कैश की गई) पढ़ सकते हैं।
या मुझे "वी" अस्थिर या परमाणु संदर्भ बनाने की आवश्यकता है?
हाँ, वे दोनों काम करते हैं।
, बनाना v
अस्थिर बस कैशिंग v
के मूल्य से सीपीयू कोर रोक यानी हर पढ़ चर v
करने के लिए/ऑपरेशन लिखने मुख्य स्मृति है, जो धीमी (लगभग 100x बार एल 1 कैश से पढ़ने की तुलना में धीमी में प्रवेश करना होगा, के लिए interaction_latency देखना विवरण)
v = new AtomicInteger()
का उपयोग कर काम करता है क्योंकि AtomicInteger
दृश्यता प्रदान करने के लिए आंतरिक रूप से private volatile int value;
का उपयोग करें।
और, यह भी अगर आप लॉक (चाहे एक Lock
वस्तु या synchronized
ब्लॉक या विधि का उपयोग करें) का उपयोग पढ़ने और लिखने धागा (के रूप में अपने दूसरे कोड खंड करता है) पर काम करता है, क्योंकि
(
Second Edition of The Java ® Virtual Machine Specification खंड 8.9 के अनुसार)
... किसी भी ताला लॉक करना धारणात्मक एक थ्रेड काम स्मृति से सभी चर flushes, और किसी भी ताला खोलने सभी चर कि धागा सौंपा है के मुख्य स्मृति के लिए बाहर लिख ...
बलों .. यदि कोई थ्रेड किसी विशेष साझा चर का उपयोग करता है o लॉक करने के बाद nly लॉक के इसी अनलॉकिंग से पहले, तो थ्रेड लॉक ऑपरेशन के बाद मुख्य मेमोरी से उस चर के साझा मूल्य को पढ़ेगा, यदि आवश्यक हो, तो को मुख्य मेमोरी में कॉपी करेगा हाल ही में अनलॉक ऑपरेशन से पहले उस चर को असाइन किया गया मान।यह, ताले के लिए आपसी बहिष्कार नियमों के साथ संयोजन के रूप में, गारंटी नहीं है कि मूल्यों साझा चर के माध्यम से एक से दूसरे धागे से सही ढंग से प्रेषित कर रहे हैं पर्याप्त ...
पी.एस. AtomicXXX
CAS
(तुलना करें और स्वैप) संचालन भी प्रदान करता है जो उत्परिवर्ती पहुंच के लिए उपयोगी है।
पी.पी.एस. इस विषय पर जेवीएम विनिर्देश जावा 6 के बाद से नहीं बदला है, इसलिए उन्हें jvm specification for java 7, 8, and 9 में शामिल नहीं किया गया है।
पीपीपीएस this article के मुताबिक, प्रत्येक कोर के दृश्य से सीपीयू कैश हमेशा सुसंगत होते हैं। आपके प्रश्न की स्थिति 'मेमोरी ऑर्डरिंग बफर' के कारण होती है, जिसमें store
& load
निर्देश (जिसका उपयोग स्मृति से डेटा लिखने और पढ़ने के लिए किया जाता है) प्रदर्शन के लिए फिर से आदेश दिया जा सकता है। विस्तार से, बफर load
निर्देश को पुराने store
निर्देश से आगे निकलने की अनुमति देता है, जो वास्तव में समस्या का कारण बनता है। हालांकि, मेरी राय में, यह समझना अधिक कठिन है, इसलिए 'विभिन्न कोर (जैसे जेवीएम चश्मा किया गया) के लिए कैश एक बेहतर अवधारणा मॉडल हो सकता है।
क्या आपका मतलब है 'ReentrantLock'? –
हां। लेकिन न केवल ReentrantLock बल्कि ग्रहण आरसीपी ढांचे से ISchedulingRule और ILock भी। –