2010-06-16 9 views
17

ऐसा कुछ है जो मुझे जावा मेमोरी मॉडल के साथ बग करता है (अगर मैं सब कुछ ठीक से समझता हूं)। यदि दो धागे ए और बी हैं, तो इस बात की कोई गारंटी नहीं है कि बी को ए द्वारा लिखे गए मान को कभी भी देखा जाएगा, जब तक कि ए और बी दोनों एक ही मॉनिटर पर सिंक्रनाइज़ न हों।क्या जावा मेमोरी मॉडल (जेएसआर -133) का मतलब है कि मॉनीटर में प्रवेश करने से सीपीयू डेटा कैश फ्लश हो जाता है?

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

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

जैसा कि अब है, यह मेरे लिए बहुत अधिक समझ में नहीं आता है। क्या कोई साफ़ कर सकता है क्यों यह विशिष्ट मेमोरी मॉडल चुना गया था?


संपादित करें: सख्त और हार का मेरा उपयोग पीछे की ओर एक खराब विकल्प था। मैंने उस मामले के लिए "सख्त" इस्तेमाल किया जहां कम गारंटी दी जाती है और विपरीत के लिए "हार" होती है। भ्रम से बचने के लिए, मजबूत या कमजोर गारंटी के मामले में बोलना बेहतर होगा।

+0

एक बात जिस पर टिप्पणी करने की आवश्यकता है वह कथन है "उसी मॉनीटर पर सिंक्रनाइज़ करें"। जैसा कि मैं समझता हूं कि उसी मॉनिटर पर सिंक्रनाइज़ेशन उस मॉनिटर के आस-पास निष्पादन आदेश की गारंटी देता है। हालांकि, मेमोरी कैश के मामले में, _any_ सिंक्रनाइज़ किए गए ब्लॉक को प्राप्त करने से कैश रीलोड हो जाता है और _any_ लॉक जारी करने से काम करने वाले CPU मेमोरी से सभी लिखने की फ्लश हो जाती है। – Gray

+0

आपके मन में कौन सा विशिष्ट कमान था? – curiousguy

उत्तर

6

सिंक्रनाइज़ करने के लिए, यहां तक ​​कि अगर कैश जुटना हार्डवेयर

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

और बेतुका आर्किटेक्चर पर दूसरी ओर खराब प्रदर्शन पर (पूर्ण कैश flushes)

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

नहीं इसे और अधिक सख्त होना चाहिए

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

AFAIK, जावा 5 एमएम (बस .NET CLR MM की तरह) x86 और IA64 जैसे सामान्य आर्किटेक्चर के मेमोरी मॉडल की तुलना में अधिक "सख्त" है। इसलिए, यह इसके बारे में तर्क अपेक्षाकृत सरल बनाता है। फिर भी, यह स्पष्ट रूप से अनुक्रमिक स्थिरता के करीब एस/टी की पेशकश नहीं करनी चाहिए क्योंकि इससे कम संकलक/जेआईटी/सीपीयू/कैश ऑप्टिमाइज़ेशन लागू किए जा सकते हैं।

+0

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

+0

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

+0

मुझे यह मानना ​​है कि मेरे पास केवल एक अंतरंग ज्ञान है प्रोसेसर परिवार और उसमें एकल लाइनों को फ्लश/अमान्य करने के साथ-साथ मेमोरी पेज (एमएमयू पेज में) के निर्देश भी शामिल हैं।चूंकि यह डीएमए करने वाले डिवाइस ड्राइवरों के लिए एक प्रदर्शन प्रासंगिक पहलू है, इसलिए मुझे लगता है कि किसी भी उचित आर्किटेक्चर के पास इसे पूरा करने का एक तरीका है। लेकिन मैं इस धारणा के साथ पूरी तरह से गलत हो सकता है। – Durandal

1

जेवीएम तक पहुंचने वाले कैश वास्तव में केवल सीपीयू रजिस्ट्रार हैं। चूंकि उनमें से कई नहीं हैं, मॉनिटर निकास पर उन्हें फ़्लश करना एक बड़ा सौदा नहीं है।

संपादित करें: (सामान्य रूप में) स्मृति कैश JVM के नियंत्रण में, JVM/लिखने/फ्लश इन कैश को पढ़ने के लिए चयन कर रहे हैं नहीं कर सकते, अत इस चर्चा में उनके बारे में भूल

कल्पना प्रत्येक सीपीयू है 1,000,000 रजिस्ट्रार JVM खुशी से पागल कंप्यूटेशंस करने के लिए उनका शोषण करता है - जब तक यह मॉनिटर में प्रवेश/बाहर निकलता है, और उसे अगले कैश परत में 1,000,000 रजिस्ट्रारों को फ्लश करना पड़ता है।

यदि हम उस दुनिया में रहते हैं, तो जावा का विश्लेषण करने के लिए पर्याप्त स्मार्ट होना चाहिए कि कौन सी वस्तुएं साझा नहीं की जाती हैं (अधिकांश वस्तुएं नहीं हैं), या प्रोग्रामर से ऐसा करने के लिए कहा जाना चाहिए।

जावा मेमोरी मॉडल एक सरलीकृत प्रोग्रामिंग मॉडल है जो औसत प्रोग्रामर ठीक मल्टीथ्रेडिंग एल्गोरिदम बनाने की अनुमति देता है। 'सरलीकृत' से मेरा मतलब है कि पूरी दुनिया में 12 लोग हो सकते हैं जो वास्तव में जेएलएस के अध्याय 17 पढ़ते हैं और वास्तव में इसे समझते हैं।

+2

मुझे नहीं लगता कि यह सही है। सीपीयू में मेगाबाइट्स के क्रम में मेमोरी कैश भी हैं जो सामने की मुख्य मेमोरी http://en.wikipedia.org/wiki/CPU_cache है। मुद्दा यह है कि जब यह कैश अपने गंदे पृष्ठों को मुख्य स्मृति में फहराता है और उन पृष्ठों को अमान्य करता है जो मुख्य स्मृति में अद्यतन किए गए हैं। – Gray

+0

कैश और रजिस्टर के अर्थशास्त्र अलग-अलग हैं - रजिस्ट्रार थ्रेड स्थानीय होते हैं, जबकि कैश थ्रेड्स (या संभवतः यहां तक ​​कि प्रक्रियाओं, आर्किटेक्चर के आधार पर) के बीच साझा किया जा सकता है। – Durandal

+0

दोस्तों, आपके द्वारा बात की जाने वाली मेमोरी कैश JVM द्वारा प्रोग्राम करने योग्य नहीं हैं, इसलिए वे हमारी चर्चा के लिए अप्रासंगिक हैं। – irreputable

4

उत्तर यह होगा कि अधिकांश मल्टीप्रोसेसर कैश-सुसंगत हैं, जिनमें बड़े NUMA सिस्टम शामिल हैं, जो लगभग? हमेशा सीसीएनएनए हैं।

मुझे लगता है कि आप कुछ हद तक उलझन में हैं कि अभ्यास में कैश कोहिरेशन कैसे लागू किया जाता है। सबसे पहले, कैश सुसंगत/सिस्टम पर कई अन्य बातों के संबंध में बेतुका हो सकता है:

  • डिवाइस
  • (मेमोरी द्वारा संशोधित) डीएमए
  • डाटा कैश बनाम अनुदेश कैश अन्य कोर पर
  • कैश/प्रोसेसर (एक इस सवाल के बारे में है)
  • ...

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

इसी तरह, जब गतिशील रूप से कोड उत्पन्न करते हैं, तो आपको निर्देश कैश को फ़्लश करने की आवश्यकता हो सकती है।

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

हालांकि यह (अंतिम) कोष्ठक बनाए रखने के लिए पर्याप्त है, यह ऑर्डरिंग की गारंटी नहीं देता है, या परिवर्तन अन्य CPUs के लिए तत्काल दिखाई दे रहे हैं। फिर, लिखने वाले बफर भी हैं, जो देरी लिखते हैं।

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

+0

मुझे पता है कि x86 के प्रभुत्व के साथ समस्या अधिक सैद्धांतिक प्रकृति का है, लेकिन अगर कोई मानता है कि हार्डवेयर में समेकन समर्थन है तो जावा मेमोरी मॉडल इसकी परिभाषा में अत्यधिक रूढ़िवादी प्रतीत होता है। डीएमए उपकरणों के साथ उदाहरण वास्तव में इस विषय पर अधिक प्रकाश नहीं डालता है, क्योंकि किसी भी डिवाइस के लिए ड्राइवर आवश्यक होने पर कैश फ्लश करने के लिए ज़िम्मेदार होगा - और जावा के विपरीत ड्राइवर * बिल्कुल जानता है * कौन सा मेमोरी एरिया प्रभावित होगा। – Durandal

+0

डिवाइस और डीएमए के बारे में बिंदु यह बताने के लिए था कि "अनौपचारिक" के लिए कई अर्थ हैं, और यह लोगों को यह विश्वास करने के लिए गुमराह कर सकता है कि एक आर्किटेक्चर चुड़ैल सुसंगत कैश असंगत है। – ninjalj

+0

और कैश कोहेन्सी के बारे में, जैसा कि मैंने समझाया है, कैश तुरंत सुसंगत नहीं हैं, लेकिन प्रोटोकॉल अंतिम सहारे सुनिश्चित करता है। बाड़ लिखने वाले बफर, अमान्यता कतार, बैंक किए गए कैश, के कारण ऑर्डरिंग और दृश्यता के मुद्दों को रोकते हैं ... – ninjalj

5

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

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

अंत में, आपको लगता है कि जावा मेमोरी मॉडल (जेएमएम) असाधारण है, जबकि नींव आजकल काफी अत्याधुनिक है, और एडा, पॉज़िक्स ताले के समान (मानक की व्याख्या के आधार पर) , और सी/सी ++ मेमोरी मॉडल। आप जेएसआर -133 कुकबुक पढ़ना चाहेंगे जो बताता है कि मौजूदा आर्किटेक्चर पर जेएमएम कैसे लागू किया गया है: http://g.oswego.edu/dl/jmm/cookbook.html

संबंधित मुद्दे