Concurrency: प्रक्रिया बनाम थ्रेड

Question

धागे के आधार पर एक पर प्रक्रियाओं के आधार पर समरूपता के लिए मॉडल का उपयोग करने के मुख्य लाभ क्या हैं और बाद में कौन से संदर्भ उपयुक्त हैं?

Answer 1

दोष-सहिष्णुता और मापनीयता प्रक्रिया बनाम थ्रेड का उपयोग करने का मुख्य लाभ हैं।

एक ऐसी प्रणाली जो साझा स्मृति या किसी अन्य प्रकार की तकनीक पर निर्भर करती है जो केवल थ्रेड का उपयोग करते समय उपलब्ध होती है, जब आप कई मशीनों पर सिस्टम को चलाने के लिए बेकार रहेंगे। जल्द या बाद में आपको विभिन्न प्रक्रियाओं के बीच संवाद करने की आवश्यकता होगी।

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

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

यह सब कहकर, ओएस प्रक्रियाओं में भी कई कमियां होती हैं जो उन्हें उपयोग करने में कठोर बनाती हैं, इस तथ्य की तरह कि यह हमेशा एक नई प्रक्रिया को जन्म देने के लिए लेता है। हालांकि, एर्लांग की प्रक्रियाओं की अपनी धारणा है, जो बेहद हल्के हैं।

इसके साथ ही, यह चर्चा वास्तव में शोध का विषय है। यदि आप अधिक जानकारी प्राप्त करना चाहते हैं, तो आप जो आर्मस्ट्रांग का पेपर गलती-सहनशील प्रणालियों पर दे सकते हैं] 1 एक पढ़ा गया है, यह एर्लांग और दर्शन के बारे में बहुत कुछ बताता है।

Answer 2

प्रक्रिया-आधारित मॉडल का उपयोग करने का नुकसान यह है कि यह धीमा हो जाएगा। आपको अपने कार्यक्रम के समवर्ती हिस्सों के बीच डेटा कॉपी करना होगा।

थ्रेड-आधारित मॉडल का उपयोग करने का नुकसान यह है कि आपको शायद यह गलत लगेगा। यह मतलब हो सकता है, लेकिन यह सच है - मुझे धागे के आधार पर कोड दिखाएं और मैं आपको एक बग दिखाऊंगा। मुझे थ्रेड कोड में बग मिली है जो 10 वर्षों के लिए "सही" चलाती है।

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

थ्रेड-आधारित मॉडल का उपयोग करने का लाभ यह है कि यह तेज़ है।

यह स्पष्ट हो सकता है कि मैं इनमें से कौन सा पसंद करता हूं, लेकिन यदि यह नहीं है: प्रक्रियाएं, सप्ताह के हर दिन और दो बार रविवार को। धागे बहुत कठिन हैं: मैंने कभी भी किसी से मुलाकात नहीं की है जो सही बहु थ्रेडेड कोड लिख सकता है; वे जो दावा करते हैं कि आमतौर पर अंतरिक्ष के बारे में पर्याप्त जानकारी नहीं है।

Answer 3

इस मामले में प्रक्रियाएं एक दूसरे से अधिक स्वतंत्र होती हैं, जबकि थ्रेड कुछ संसाधन साझा करते हैं उदा। याद। लेकिन एक सामान्य मामले में थ्रेड प्रक्रियाओं की तुलना में अधिक हल्के वजन होते हैं।

एरलांग प्रक्रिया ओएस प्रक्रियाओं की तरह ही नहीं है। Erlang प्रक्रियाएं बहुत हल्के वजन वाले हैं और एर्लांग में एक ही ओएस थ्रेड के भीतर कई एर्लांग प्रक्रियाएं हो सकती हैं।Technically why is processes in Erlang more efficient than OS threads?

Answer 4

सबसे पहले देखें और सबसे महत्वपूर्ण, प्रक्रियाओं अधिकांशतः इस बात उनकी स्मृति नियंत्रित किया जाता है में धागे से अलग:

Process = n*Thread + memory region (n>=1) 

प्रक्रियाओं को अपने स्वयं के अलग स्मृति है। प्रक्रियाओं में एकाधिक धागे हो सकते हैं।

प्रक्रियाओं को ऑपरेटिंग सिस्टम स्तर पर एक-दूसरे से पृथक किया जाता है। थ्रेड प्रक्रिया में अपने साथियों के साथ अपनी याददाश्त साझा करते हैं। (यह अक्सर अवांछित होता है। इसका समाधान करने के लिए वहां पुस्तकालय और विधियां हैं, लेकिन आमतौर पर ऑपरेटिंग सिस्टम थ्रेड पर कृत्रिम परत होती है।)

स्मृति की बात सबसे महत्वपूर्ण समझदार कारक है, क्योंकि इसमें कुछ प्रभाव हैं :

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

प्रक्रियाओं का उपयोग करके आपको अच्छा (या परम) encapsulation देता है। चूंकि अंतर प्रक्रिया संचार को विशेष प्रयास की आवश्यकता होती है, इसलिए आपको एक स्वच्छ इंटरफेस को परिभाषित करने के लिए मजबूर किया जाएगा। मुख्य निष्पादन योग्य से अपने आवेदन के कुछ हिस्सों को तोड़ना एक अच्छा विचार है। शायद आप इस तरह निर्भरताओं को विभाजित कर सकते हैं। उदा। Process_RobotAi <-> Process_RobotControl एआई नियंत्रण कक्ष की तुलना में काफी अलग निर्भरता होगी। इंटरफ़ेस सरल हो सकता है: Process_RobotAI --DriveXY--> Process_RobotControl। शायद आप रोबोट प्लेटफॉर्म बदल सकते हैं। आपको केवल उस सरल इंटरफेस के साथ एक नया RobotControl निष्पादन योग्य लागू करना होगा। आपको अपने एआई घटक में कुछ भी स्पर्श या फिर भी कंपाइल करने की ज़रूरत नहीं है।

यह भी इसी कारण से, अधिकांश मामलों में संकलन को तेज करेगा।

संपादित करें: बस पूर्णता के लिए मैं दूसरों को याद दिलाता हूं कि दूसरों ने मुझे याद दिलाया है: एक क्रैशिंग प्रक्रिया आपके पूरे एप्लिकेशन को क्रैश नहीं करती है।

जनरल में:

1. कुछ अत्यधिक समवर्ती या synchronuous, एन के साथ एक एल्गोरिथ्म >> 1 उदाहरणों समानांतर और डेटा साझा करने, उपयोग धागे में चल तरह बनाना चाहते हैं।
2. एक ऐसे सिस्टम के साथ एक सिस्टम है जिसमें डेटा या एल्गोरिदम साझा करने की आवश्यकता नहीं है, न ही वे अक्सर डेटा का आदान-प्रदान करते हैं, प्रक्रियाओं का उपयोग करते हैं। यदि आप इंटर प्रोसेस संचार के लिए आरपीसी लाइब्रेरी का उपयोग करते हैं, तो आपको कोई अतिरिक्त लागत पर नेटवर्क-वितरित समाधान मिलता है।

1 और 2 चरम और नो-ब्रेनर परिदृश्य हैं, बीच में सबकुछ व्यक्तिगत रूप से तय किया जाना चाहिए।

आईपीसी/आरपीसी का उपयोग करने वाली प्रणाली के अच्छे (या भयानक) उदाहरण के लिए, ros पर एक नज़र डालें।