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

• मॉनिटरर : मॉनिटर कैप्चर। एक समय में, केवल एक धागा ही एक मॉनिटर का मालिक हो सकता है। यदि मॉनिटर कैप्चर प्रयास के समय में व्यस्त है, तो इसे पकड़ने का प्रयास करने वाला थ्रेड तब तक इंतजार करेगा जब तक यह रिलीज़ नहीं हो जाता। इस स्थिति में, कतार में कई थ्रेड हो सकते हैं।
• monitorexit : मुफ्त मॉनिटर
• प्रतीक्षा करें : वर्तमान थ्रेड को मॉनिटर के तथाकथित प्रतीक्षा सेट पर ले जाने और notify होने की प्रतीक्षा करने के लिए। wait विधि से बाहर निकलना भी गलत हो सकता है। मॉनिटर का मालिक होने वाले थ्रेड के बाद, कोई भी थ्रेड मॉनिटर पर अधिकार कर सकता है।
• सूचित करें (सभी) : उन थ्रेड्स में से एक (या सभी) को जगाता है जो वर्तमान में मॉनिटर के प्रतीक्षा सेट में हैं। नियंत्रण पाने के लिए, जागृत धारा को मॉनीटर (निगरानीकर्ता) पर सफलतापूर्वक कब्जा करना चाहिए

विवाद - एक स्थिति जब कई इकाइयां एक साथ एक ही संसाधन के लिए प्रयास करती हैं, जो विशेष उपयोग के लिए अभिप्रेत है

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

ऑब्जेक्ट हेडर

शब्दों को चिह्नित करें सामग्री

 Identity hashcode 

 age 

 0 

     mark word 

 id - 

 epoch 

 age 

 1 

क्या आपने देखा कि पक्षपातपूर्ण होने के मामले में, पहचान के हैश कोड और थ्रेडिड + युग दोनों के लिए एक ही समय में पर्याप्त स्थान नहीं था? और यह ऐसा है, और यहाँ से एक दिलचस्प परिणाम है: हॉटस्पॉट में, System.identityHashCode को कॉल करने से ऑब्जेक्ट का रिवोक पूर्वाग्रह होगा।

synchronized का उपयोग करने का एक सरल उदाहरण

 1 2 3 4 5 6 7 

 public class SynchronizedSample { void doSomething() { synchronized(this) { // Do something } } } 

 javac SynchronizedSample.java && javap -c SynchronizedSample 

 void doSomething(); Code: 0: aload_0 //    this 1: dup //    (this) 2: astore_1 //      (this)   1 3: monitorenter //   ,     (this) 4: aload_1 //   this   5: monitorexit //   6: goto 14 //  "catch-" 9: astore_2 // (  ,   )     2 10: aload_1 //  this    11: monitorexit //   12: aload_2 //      13: athrow //   14: return //  Exception table: from to target type 4 6 9 any //      ,   "catch-" 9 12 9 any //   ,     

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

monitorenter

 ./bytecodes.hpp:235: _monitorenter = 194, // 0xc2 ./bytecodes.cpp:489: def(_monitorenter, "monitorenter", "b", NULL, T_VOID, -1, true); 

कैस - तुलना और अदला - बदली, तुलना *dest compare_value और compare_value , और अगर वे समान हैं, *dest स्थानों exchange_value *dest compare_value और exchange_value । प्रारंभिक मूल्य *dest वापस आ गया है। (एक ही समय में, दो-तरफा मेमबर की गारंटी है, लेकिन अगले लेख में उनके बारे में अधिक)

 CALL_VM(InterpreterRuntime::monitorenter(THREAD, entry), handle_exception); 

fast_enter

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

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

slow_enter

1. केस एक, "अच्छा" : ऑब्जेक्ट का मॉनिटर वर्तमान में मुफ्त है। फिर हम कैस का उपयोग करके उस पर कब्जा करने की कोशिश करते हैं। कैस पहले से ही एक आर्किटेक्चर-निर्भर (और आमतौर पर मूल रूप से प्रोसेसर द्वारा समर्थित) निर्देश है, इसलिए गहराई में जाने का कोई मतलब नहीं है। (हालांकि रुस्लान # उसे एक चेरमिन हेनवीट देते हैं , मैं इस बात से नाराज था कि मुझे "एमओएस ट्रांजिस्टर के स्रोत-सिंक में इलेक्ट्रॉनों के चलने के लिए नहीं मिला था") । यदि कैस सफल होता है, तो जीत: मॉनिटर पर कब्जा कर लिया जाता है। यदि यह विफल हो जाता है, तो हम दुख से भर जाते हैं और तीसरे मामले में आगे बढ़ते हैं।
   
   
2. केस टू भी "अच्छा" है : ऑब्जेक्ट का मॉनिटर मुक्त नहीं है, लेकिन यह उसी स्ट्रीम के साथ व्यस्त है जो अब इसे पकड़ने की कोशिश कर रहा है। यह एक पुनरावर्ती कब्जा है। इस मामले में, सादगी के लिए, हम अपने स्टैक NULL में विस्थापित हेडर को लिखते हैं, क्योंकि पहले ही हमने इस मॉनिटर को पहले ही कैप्चर कर लिया था और हमारे स्टैक में इसके बारे में पहले से ही जानकारी है।
   
   
3. केस थ्री, "बुरा" भड़कता है : इसलिए, असफलता के साथ चाल दिखाने के सभी प्रयास विफल हो गए हैं, और हमारे पास कुछ भी करने के लिए नहीं है, लेकिन विराम देने के लिए, उपयोगकर्ता की भाषा को दिखाने और segfault से गिर जाते हैं। Haha। एक चुटकुला। हालाँकि, मैंने केवल पॉउटिंग के बारे में कुछ नहीं कहा: उस स्थिति में जब आपको "ईमानदारी से" कार्य करना होगा, ओएस स्तर की प्राथमिकताओं का सहारा लेते हुए, वे कहते हैं कि मॉनिटर को फुलाया गया था । कोड में, इस व्यवहार को ObjectSynchronizer::inflate में वर्णित किया गया है, जहां हम बहुत सावधानी से नहीं देखेंगे: वास्तव में, विधि थ्रेड-सुरक्षित है और, कुछ तकनीकी बारीकियों को ध्यान में रखते हुए, ध्वज को मॉनिटर पर सेट किया जाता है कि यह फूला हुआ है।
   
   मॉनिटर को फुलाए जाने के बाद, आपको इसमें जाने की आवश्यकता है। ObjectMonitor::enter विधि सिर्फ इतना है कि, धारा को ObjectMonitor::enter करने से बचने के लिए सभी कल्पनीय और अकल्पनीय तरकीबें लागू करती है। इन चालों में शामिल हैं, जैसा कि आप अनुमान लगा सकते हैं, एक स्पिन लूप का उपयोग करके कैप्चर करने का प्रयास, एक बार CAS-s और अन्य "फ्री मेथड्स" का उपयोग करके। वैसे, ऐसा लगता है कि मुझे टिप्पणियों और क्या हो रहा है के बीच थोड़ी विसंगति मिली। एक बार जब हम एक स्पिन लूप के साथ मॉनिटर में प्रवेश करने का प्रयास करते हैं, तो दावा करते हैं कि हम इसे केवल एक बार करते हैं:
   
   

   352 353 354 355 356 357 358 359 360 361 362 363

   // Try one round of spinning *before* enqueueing Self // and before going through the awkward and expensive state // transitions. The following spin is strictly optional ... // Note that if we acquire the monitor from an initial spin // we forgo posting JVMTI events and firing DTRACE probes. if (Knob_SpinEarly && TrySpin (Self) > 0) { assert (_owner == Self , "invariant") ; assert (_recursions == 0 , "invariant") ; assert (((oop)(object()))->mark() == markOopDesc::encode(this), "invariant") ; Self->_Stalled = 0 ; return ; }

   
   
   और यहाँ थोड़ा आगे, तथाकथित enterI विधि में, enterI इसे फिर से करते हैं, फिर से केवल एक बार बोलते हैं:
   
   

   485 486 487 488 489 490 491 492 493 494 495 496 497

   // We try one round of spinning *before* enqueueing Self. // // If the _owner is ready but OFFPROC we could use a YieldTo() // operation to donate the remainder of this thread's quantum // to the owner. This has subtle but beneficial affinity // effects. if (TrySpin (Self) > 0) { assert (_owner == Self , "invariant") ; assert (_succ != Self , "invariant") ; assert (_Responsible != Self , "invariant") ; return ; }

   
   
   ठीक है, ऑपरेटिंग सिस्टम स्तर पर पार्किंग इतनी डरावनी है कि हम इससे बचने के लिए लगभग किसी भी चीज के लिए तैयार हैं। आइए देखें कि उसमें क्या भयानक है।
   
   

   पार्किंग की विपरीत धाराएँ

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

   591 592 593 594 595 596 597 598 599 600 601

   // park self if (_Responsible == Self || (SyncFlags & 1)) { TEVENT (Inflated enter - park TIMED) ; Self->_ParkEvent->park ((jlong) RecheckInterval) ; // Increase the RecheckInterval, but clamp the value. RecheckInterval *= 8 ; if (RecheckInterval > 1000) RecheckInterval = 1000 ; } else { TEVENT (Inflated enter - park UNTIMED) ; Self->_ParkEvent->park() ; }

   
   
   सीधे पार्किंग स्थल पर जाने से पहले, हम इस तथ्य पर ध्यान देते हैं कि यहां यह समयबद्ध हो सकता है या नहीं, यह इस पर निर्भर करता है कि वर्तमान धारा जिम्मेदार है। हमेशा एक से अधिक जिम्मेदार प्रवाह नहीं होते हैं, और तथाकथित फंसे से बचने के लिए उनकी आवश्यकता होती है: मॉनिटर मुक्त होने पर दु: ख, लेकिन प्रतीक्षा सेट में सभी प्रवाह अभी भी पार्क किए गए हैं और एक चमत्कार की प्रतीक्षा कर रहे हैं। जब कोई व्यक्ति प्रभारी होता है, तो वह स्वचालित रूप से समय-समय पर उठता है (अधिक व्यर्थ जागने - जागने के बाद, जिसके बाद लॉक पर कब्जा करना संभव नहीं था - पार्किंग समय। कृपया ध्यान दें कि यह 1000 एमएस से अधिक नहीं है) और मॉनिटर में प्रवेश करने की कोशिश करता है। बाकी प्रवाह कम से कम अनंत काल तक जागृति की प्रतीक्षा कर सकते हैं।
   
   अब पार्किंग के बहुत सार पर आगे बढ़ने का समय है। जैसा कि आप पहले से ही समझ चुके हैं, यह वाट्स wait/notify जावा डेवलपर के समान ही शब्दार्थ में कुछ है, जो ऑपरेटिंग सिस्टम के स्तर पर होता है। उदाहरण के लिए, linux और bsd में, जैसा कि आप उम्मीद कर सकते हैं, POSIX थ्रेड्स का उपयोग किया जाता है, जिसमें pthread_cond_timedwait (या pthread_cond_wait ) को मॉनीटर को फ्री करने के लिए प्रतीक्षा करने के लिए कहा जाता है। ये विधियाँ Linux थ्रेड की स्थिति को WAITING में बदल देती हैं और सिस्टम शेड्यूलर से पूछती हैं कि जब कोई घटना घटती है (लेकिन बाद में यह धागा जिम्मेदार होता है तो कुछ समय बाद नहीं)।
   
   

   OS स्तर थ्रेड शेड्यूलिंग

   खैर, यह लाइनक्स कर्नेल में आने का समय है और देखें कि वहां शेड्यूलर कैसे काम करता है। लिनक्स स्रोत, जैसा कि आप जानते हैं, गिट में हैं, और आप इस तरह से एक शेड्यूलर क्लोन कर सकते हैं:
   
   

    git clone git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-rt.git 

   
   
   चलो फ़ोल्डर में जाओ ... ठीक है, ठीक है, मैं मजाक कर रहा हूं। स्रोत कोड में लाइनों तक लिनक्स शेडयूलर डिवाइस की विशेषताएं पहले से ही एक सहज लेख के लिए बहुत गहरी हैं, जो आपको याद दिलाता हूं, एक साधारण synchronized ब्लॉक के साथ शुरू किया गया :) कट्टर को कम करने के लिए, मैं आपको सामान्य शब्दों में बताता हूं कि सामान्य रूप से शेड्यूलर कैसे काम करते हैं; दोनों लिनक्स में और वैकल्पिक प्रणालियों में। - , , : — , . — quantum — , , , . linux , 10-200 , 1 . windows , 2-15 , — 10 15 .
   
   , , , . , , (, - I/O-), , - . - . , , , -, , .
   
   , , , — . , , , , , , .
   
   , , : , — , . : , , -, .
   
   , , , . , contention, .

monitorexit

नायब: synchronizedतरीके

 synchronized void doSomething() { // Do something } 

 synchronized void doSomething(); Code: 0: return 

प्रतीक्षा करें और सूचित करें

स्मृति प्रभाव

मेजर ओ। उर्फ़ डिस्क्लेमर से टिप्पणी

देखते रहो

और एक और बात ©