कैसे, अगर बिल्कुल, Erlang प्रक्रियाओं को कर्नेल थ्रेड के लिए मानचित्र करते हैं?

Question

एरलांग कई हल्के प्रक्रियाओं का समर्थन करने में सक्षम होने के लिए जाना जाता है; यह ऐसा इसलिए कर सकता है क्योंकि ये पारंपरिक अर्थों में या पी-धागे जैसे थ्रेड भी नहीं हैं, लेकिन पूरी तरह से उपयोगकर्ता स्थान में धागे हैं।

यह अच्छी और अच्छी (शानदार वास्तव में) है। लेकिन फिर मल्टीकोर/मल्टीप्रोसेसर पर्यावरण में समानांतर में एर्लांग धागे को कैसे निष्पादित किया जाता है? निश्चित रूप से उन्हें अलग-अलग कोर पर निष्पादित करने के लिए किसी भी तरह से कर्नेल धागे में मैप किया जाना चाहिए?

मान लीजिए कि यह मामला है, यह कैसे किया जाता है? क्या कई हल्के प्रक्रियाएं एक कर्नेल थ्रेड में मैप की गई हैं?

या इस समस्या के आसपास कोई और तरीका है?

Answer 1

उत्तर वी एम पर निर्भर करता है जो प्रयोग किया जाता है:

1) गैर SMP: वहाँ एक अनुसूचक (ओएस धागा) है, जो सभी Erlang प्रक्रियाओं कार्यान्वित करता है, runnable प्रक्रियाओं के पूल से लिया है

2) SMP (जो लोग जैसे receive द्वारा अवरुद्ध नहीं कर रहे हैं यानी): कश्मीर शेड्यूलर (ओएस धागे हैं, कश्मीर आमतौर पर सीपीयू कोर के एक नंबर) है, जो Erlang निष्पादित करता है से साझा प्रक्रिया कतार से प्रक्रियाएं। यह एक साधारण फीफो कतार है (कई ओएस धागे से एक साथ पहुंच की अनुमति देने के लिए ताले के साथ)।

3) R13B में SMP और नए: वहाँ हो जाएगा कश्मीर शेड्यूलर (पहले की तरह) जो कई प्रक्रिया कतारों से Erlang प्रक्रियाओं निष्पादित करता है। प्रत्येक शेड्यूलर की अपनी कतार होती है, इसलिए एक शेड्यूलर से दूसरे शेड्यूलर माइग्रेशन लॉजिक को जोड़ा जाएगा। यह समाधान साझा प्रक्रिया कतार में अत्यधिक लॉकिंग से बचकर प्रदर्शन में सुधार करेगा।

अधिक जानकारी के लिए this document Erlang उपयोगकर्ता सम्मेलन, स्टॉकहोम, 13 नवम्बर के लिए केनेथ लुंडिन, एरिक्सन एबी, द्वारा तैयार दिखाई देता है तो 2008

Answer 2

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

Answer 3

मैं पिछले जवाब संशोधन करना चाहते हैं।

एरलांग, या बल्कि एरलांग रनटाइम सिस्टम (इर्ट्स), शेड्यूलर की संख्या (ओएस थ्रेड्स) और आपके प्लेटफ़ॉर्म पर प्रसंस्करण तत्वों की संख्या के लिए रनक्यू की संख्या को डिफ़ॉल्ट करता है। वह प्रोसेसर कोर या हार्डवेयर धागे है। आप इन सेटिंग्स को रनटाइम में बदल सकते हैं:

erlang:system_flag(schedulers_online, NP) -> PrevNP 

Erlang प्रक्रियाओं को अभी तक किसी भी शेड्यूलर के साथ कोई संबंध नहीं है। शेड्यूलर के बीच प्रक्रियाओं को संतुलित करने का तर्क दो नियमों का पालन करता है। 1) एक भूखा शेड्यूलर दूसरे शेड्यूलर से काम चुरा लेगा। 2) माइग्रेशन पथ शेड्यूलर से प्रक्रियाओं को धक्का देने के लिए बहुत सी प्रक्रियाओं के साथ शेड्यूलर को कम काम के साथ सेटअप करने के लिए सेट हैं।यह प्रत्येक प्रक्रिया के लिए कमी गणना (निष्पादन समय) में निष्पक्षता सुनिश्चित करने के लिए किया जाता है।

शेड्यूलर हालांकि विशिष्ट प्रसंस्करण तत्वों को लॉक किया जा सकता है। यह डिफ़ॉल्ट रूप से नहीं किया जाता है।

erlang:system_flag(scheduler_bind_type, default_bind) -> PrevBind 

कई अन्य बाँध प्रकार प्रलेखन में पाया जा सकता है: ERTS scheduler-> कोर आत्मीयता उपयोग करते हैं करने के लिए। एफ़िनिटी का उपयोग भारी भार स्थितियों में प्रदर्शन में काफी सुधार कर सकते हैं! विशेष रूप से उच्च ताला विवाद स्थितियों में। इसके अलावा, लिनक्स कर्नेल कम से कम कहने के लिए हाइपरथ्रेड को संभाल नहीं सकता है। यदि आपके प्लेटफ़ॉर्म पर हाइपरथ्रेड हैं तो आपको वास्तव में इस सुविधा का उपयोग erlang में करना चाहिए।

Answer 4

मैं स्वीकृत उत्तर में वर्णित कुछ इनपुट जोड़ना चाहता हूं।

एरलांग शेड्यूलर एरलांग रनटाइम सिस्टम का एक अनिवार्य हिस्सा है और ओएस थ्रेड्स के ऊपर हल्के प्रक्रियाओं की अवधारणा के अपने स्वयं के अमूर्तता और कार्यान्वयन प्रदान करता है।

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

अब, जब Erlang प्रक्रिया बनाया जा रहा है यह पूरी तरह से ERTS और समयबद्धक जीवन चक्र और संसाधनों की खपत और साथ ही अपनी स्मृति पदचिह्न का प्रबंधन करने की जिम्मेदारी है आदि

कोर कार्यान्वयन विवरण में से एक यह है कि प्रत्येक प्रक्रिया में 2000 कटौती का समय बजट उपलब्ध होता है जब शेड्यूलर उस प्रक्रिया को रन कतार से उठाता है। सिस्टम में प्रत्येक प्रगति (यहां तक ​​कि I/O) को कटौती बजट की गारंटी है। यही कारण है कि वास्तव में ईआरटीएस को प्रीपेप्टिव मल्टीटास्किंग के साथ एक सिस्टम बनाता है।

मैं जेस्पर लुइस एंडरसन http://jlouisramblings.blogspot.com/2013/01/how-erlang-does-scheduling.html

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