📙 🚢 🕑 रूबी में जीआईएल कैसे काम करता है। भाग 1 🚵🏻 ⚾️ 👨🏼‍💻

चार में से पांच डेवलपर्स स्वीकार करते हैं कि बहु-थ्रेडेड प्रोग्रामिंग को समझना आसान नहीं है।

ज्यादातर समय मैंने रूबी समुदाय में बिताया, कुख्यात GIL मेरे लिए एक काला घोड़ा बना रहा। इस लेख में मैं जीआईएल को बेहतर तरीके से जानने के बारे में बात करूंगा।

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

मैं जानना चाहता था कि जीआईएल तकनीकी दृष्टिकोण से कैसे काम करता है। GIL पर कोई विनिर्देश या दस्तावेज नहीं है। यह अनिवार्य रूप से एमआरआई (मैट्स रूबी इंप्लीमेंटेशन) की एक विशेषता है। MRI डेवलपमेंट टीम कुछ नहीं कहती है कि GIL कैसे काम करता है और क्या गारंटी देता है।

हालांकि, मैं खुद से आगे निकल रहा हूं।

यदि आपको GIL के बारे में कुछ भी पता नहीं है, तो यहां एक संक्षिप्त विवरण दिया गया है:

MRI में कुछ है जिसे GIL (ग्लोबल इंटरप्रेटर लॉक) कहा जाता है। इसके लिए धन्यवाद, एक बहु-थ्रेडेड वातावरण में, किसी समय में, रूबी-कोड को केवल एक धागे में निष्पादित किया जा सकता है।

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

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

किसी सरणी में आइटम जोड़ना सुरक्षित नहीं है

रूबी में, थोड़ा धागा सुरक्षित है। उदाहरण के लिए एक तत्व को एक सरणी में जोड़ें

array = [] 5.times.map do Thread.new do 1000.times do array << nil end end end.each(&:join) puts array.size

इस उदाहरण में, प्रत्येक पांच सूत्र nil ही सरणी में nil हजार गुना nil जोड़ते हैं। नतीजतन, सरणी में पांच हजार तत्व होने चाहिए, है ना?

 $ ruby pushing_nil.rb 5000 $ jruby pushing_nil.rb 4446 $ rbx pushing_nil.rb 3088

= (

यहां तक कि इस तरह के एक सरल उदाहरण में, हमें गैर-थ्रेड-सुरक्षित संचालन का सामना करना पड़ता है। हम समझेंगे कि क्या हो रहा है।

आइए इस तथ्य पर ध्यान दें कि एमआरआई का उपयोग करके कोड चलाने से सही परिणाम मिलता है ( शायद इस संदर्भ में आप शब्द "अपेक्षित" - लगभग। प्रति ) पसंद करेंगे , जबकि परिणाम, जबकि रूबी और रुबिनियस नहीं करते हैं। यदि आप फिर से कोड चलाते हैं, तो स्थिति को दोहराया जाएगा, जिसमें JRuby और Rubinius अन्य (अभी भी गलत) परिणाम दे रहे हैं।

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

समवर्ती धागे डेटा अखंडता से समझौता क्यों कर सकते हैं

यह कैसे हो सकता है? सोचा कि रूबी यह अनुमति नहीं देगी? आइए देखें कि यह तकनीकी रूप से कैसे संभव है।

चाहे MRI, JRuby या Rubinius, Ruby को किसी अन्य भाषा में लागू किया गया हो: MRI को C, JRuby को Java में और Rubinius को Ruby और C ++ में लिखा जाता है। इसलिए, जब रूबी में एक भी ऑपरेशन करते हैं, उदाहरण के लिए, array << nil , यह पता चला सकता है कि इसके कार्यान्वयन में दसियों या कोड की सैकड़ों लाइनें भी शामिल हैं। यहाँ MRI में Array#<< का कार्यान्वयन है:

 VALUE rb_ary_push(VALUE ary, VALUE item) { long idx = RARRAY_LEN(ary); ary_ensure_room_for_push(ary, 1); RARRAY_ASET(ary, idx, item); ARY_SET_LEN(ary, idx + 1); return ary; }

ध्यान दें कि कम से कम चार अलग-अलग ऑपरेशन हैं:

वर्तमान सरणी लंबाई हो रही है
किसी अन्य आइटम के लिए स्मृति की जाँच करें
किसी सरणी में एक आइटम जोड़ना
सरणी की लंबाई को पुराने मान + 1 पर असाइन करना

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

लेकिन अगर हम कई थ्रेड्स के साथ काम कर रहे हैं, तो ऐसा नहीं किया जा सकता है। यदि हमारे पास दो धागे हैं, तो वे फ़ंक्शन कोड के विभिन्न भागों को निष्पादित कर सकते हैं और आपको कोड निष्पादन की दो श्रृंखलाओं का पालन करना होगा।

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

प्रारंभ में, सिस्टम निम्न स्थिति में है:

हमारे पास दो धागे हैं, जिनमें से प्रत्येक एक फ़ंक्शन को निष्पादित करने के लिए शुरू होने वाला है। चरण 1-4 ऊपर दिए गए MRI में Array#<< के कार्यान्वयन का छद्म कोड है। निम्नलिखित घटनाओं का संभावित विकास है (समय के शुरुआती समय में, प्रवाह ए सक्रिय है):

समझने के लिए कि क्या हो रहा है, बस तीर का पालन करें। मैंने प्रत्येक धारा के संदर्भ में चीजों की स्थिति को दर्शाते हुए शिलालेख जोड़े।

यह संभावित परिदृश्यों में से एक है:

थ्रेड ए फ़ंक्शन कोड को निष्पादित करना शुरू करता है, लेकिन जब कतार चरण 3 पर जाती है, तो संदर्भ स्विच हो जाता है। थ्रेड ए पॉज़ और यह थ्रेड बी की बारी है, जो सभी फ़ंक्शन कोड को निष्पादित करता है, एक तत्व जोड़कर और सरणी की लंबाई बढ़ाता है।

उसके बाद, थ्रेड ए उस बिंदु से बिल्कुल शुरू होता है जिस पर इसे रोका गया था, और यह सरणी की लंबाई बढ़ाने से ठीक पहले हुआ था। थ्रेड A सरणी की लंबाई को 1 सेट करता है। लेकिन धारा बी पहले ही डेटा को बदलने में कामयाब रही है।

एक बार फिर: थ्रेड बी सरणी की लंबाई को 1 सेट करता है, जिसके बाद थ्रेड ए इसे 1 भी असाइन करता है, इस तथ्य के बावजूद कि दोनों थ्रेड्स ने तत्वों को सरणी में जोड़ा। डेटा अखंडता टूट गई है।

और मैं रूबी पर निर्भर था

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

यदि आप JRuby या Rubinius का उपयोग करके कई बार ऊपर का उदाहरण चलाते हैं, तो आप देखेंगे कि परिणाम हमेशा अलग होता है। प्रसंग स्विचिंग अप्रत्याशित है। यह जल्द या बाद में हो सकता है, या बिल्कुल भी नहीं। मैं अगले भाग में इस विषय पर बात करूंगा।

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

मैंने अभी तक जीआईएल के कार्यान्वयन के तकनीकी विवरणों को नहीं छुआ है, और मुख्य प्रश्न अभी भी अनुत्तरित है: एमआरआई पर कोड चलाना अभी भी सही परिणाम क्यों देता है?

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

लेकिन पहले ...

योजनाकार को दोष दें

प्रसंग स्विचिंग OS अनुसूचक का कार्य है। सभी उल्लिखित कार्यान्वयन में, एक देशी धागा एक रूबी धागे से मेल खाता है। ओएस को यह सुनिश्चित करना चाहिए कि कोई भी धागा सभी उपलब्ध संसाधनों (उदाहरण के लिए सीपीयू समय) पर कब्जा नहीं करता है, इसलिए यह एक अनुसूची को लागू करता है ताकि प्रत्येक धागे को संसाधनों तक पहुंच मिल सके।

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

यह ओएस के दृष्टिकोण से प्रभावी है, लेकिन कुछ यादृच्छिकता का परिचय देता है और कार्यक्रम की शुद्धता पर दृश्य पर पुनर्विचार करने के लिए प्रेरित करता है। उदाहरण के लिए, Array#<< को निष्पादित करते समय यह ध्यान में रखा जाना चाहिए कि एक थ्रेड को किसी भी समय रोका जा सकता है और एक अन्य थ्रेड समान कोड को सामान्य डेटा को बदलते हुए निष्पादित कर सकता है।

समाधान? परमाणु संचालन का उपयोग करें

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

अवरुद्ध करने के लिए एक परमाणु ऑपरेशन का उपयोग करने का सबसे सरल तरीका है। निम्नलिखित कोड mutex के लिए MRI, JRuby और Rubinius धन्यवाद के साथ एक ही अनुमानित परिणाम देगा।

 array = [] mutex = Mutex.new 5.times.map do Thread.new do mutex.synchronize do 1000.times do array << nil end end end end.each(&:join) puts array.size

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

जीआईएल भी एक ताला है

हमने देखा कि आप परमाणु संचालन बनाने और थ्रेड सुरक्षा सुनिश्चित करने के लिए लॉकिंग का उपयोग कैसे कर सकते हैं। जीआईएल भी एक ताला है, लेकिन क्या यह कोड थ्रेड को सुरक्षित बनाता है? क्या GIL एक array << nil बदल देता है array << nil एक परमाणु ऑपरेशन में?

~~जल्द ही परी कथा प्रभावित होती है, लेकिन जल्द ही बात नहीं बनती है~~ एक समय में पढ़ा जाने वाला लेख बहुत बड़ा है, इसलिए मैंने इसे दो भागों में विभाजित किया। दूसरे भाग में, हम उन सवालों के जवाब देने के लिए MRI में GIL के कार्यान्वयन को देखेंगे।

अनुवादक टिप्पणी और रचनात्मक आलोचना सुनकर खुश होगा।

रूबी में जीआईएल कैसे काम करता है। भाग 1