2011-03-03 17 views
5

मेरे पास एक सिस्टम एप्लीकेशन है, जो यूनिक्स पर 12 प्रक्रियाओं पर संग्रह के रूप में चलता है। एक मॉनीटर प्रक्रिया है, जो 11 अन्य प्रक्रियाओं से डेटा का आदान-प्रदान करती है।कौन सा आईपीसी यहां अधिक कुशल है?

आईपीसी आवश्यकता इन 11 प्रक्रियाओं को मॉनीटर प्रक्रिया के साथ संवाद करने के लिए है, जो कि निष्पादन के मामले में सबसे कुशल है। क्या आप नीचे दिए गए दो विकल्पों का वजन कर सकते हैं, या एक बेहतर सुझाव दे सकते हैं।

1) एक यूडीपी सॉकेट संचार है, जहां ये 11 प्रक्रिया आवधिक अंतराल पर मॉनीटर प्रक्रिया में डेटा को धक्का देगी। मॉनीटर प्रक्रिया सिर्फ सुनने और जानकारी को कैप्चर कर रही है जो काफी अच्छी है।

या

2) एक साझा स्मृति कार्यान्वयन है। इसलिए 11 साझा मेमोरी सेगमेंट हैं, जहां प्रत्येक को 2 प्रक्रियाओं (प्रक्रिया ith और मॉनिटर प्रक्रिया) के बीच साझा किया जाता है।

साझा स्मृति के लिए, यह तेज़ी से प्रतीत होता है लेकिन लॉकिंग/सिंक आवश्यक है, जहां कर्नेल udp में डेटा को एक प्रक्रिया के स्मृति स्थान से दूसरी प्रतिलिपि बनाता है।

क्या कोई भी दो तरीकों का बेहतर मूल्यांकन करने में सहायता के लिए अधिक इनपुट प्रदान कर सकता है। ? धन्यवाद।

+3

क्या आप वास्तव में यूडीपी सॉकेट का मतलब है, या क्या आपका मतलब यूनिक्स डोमेन सॉकेट है? –

उत्तर

5

साझा स्मृति को समन्वय करना मुश्किल है। माता-पिता को पता होना चाहिए कि 11 साझा किए गए मेमोरी सेगमेंट में से प्रत्येक का कौन सा हिस्सा पढ़ना है, और बच्चे को यह जानने दें कि डेटा को कब पढ़ा गया है ताकि साझा मेमोरी का हिस्सा पुन: उपयोग किया जा सके। इसलिए, हालांकि प्रतिलिपि हो सकती है जल्दी, शेष समन्वय (शायद सेमफोर सेट का उपयोग करना - शायद 22 सेमेफोरस के साथ, 11 संचार चैनलों की प्रत्येक दिशा के लिए) का अर्थ है कि आपको लगभग निश्चित रूप से फ़ाइल-डिस्क्रिप्टर आधारित तंत्र को कोड के लिए बहुत आसान लगेगा। select() या poll() या वेरिएंट सिस्टम कॉल का उपयोग आपको यह बताने के लिए किया जा सकता है कि मास्टर को पढ़ने के लिए डेटा कब होता है। और कर्नेल शेड्यूलिंग और फ्लो कंट्रोल के सभी ग़लत मुद्दों से संबंधित है और इसी तरह।

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

2

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

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

+1

1) डेटा औसत के क्रम में होगा: 30 केबी/मिनट (लोड के बारे में 60 केबी/मिनट)।2) कोड की आसानी चिंता का विषय नहीं है क्योंकि हमारे पास सबसे अधिक प्रदर्शन उन्मुख बनाने के लिए समय और प्रयास है। – sbr

+2

60 किलोबाइट प्रति मिनट एक आधुनिक कंप्यूटर के लिए एक नगण्य भार है (यहां तक ​​कि एक आधुनिक एम्बेडेड कंप्यूटर के लिए)। यदि आपका भार वास्तव में कम है, तो यह मुश्किल से मायने रखता है कि आप चीजों को कैसे कार्यान्वित करते हैं; आपको किसी भी उचित तंत्र के साथ अच्छा प्रदर्शन मिलेगा। मैं एक जटिल तंत्र पर बहुत से प्रोग्रामिंग घंटे नहीं व्यतीत करूंगा जब एकमात्र लाभ यह होगा कि आप 0.02% के बजाय 0.01% CPU उपयोग देख सकते हैं। अगर यह मैं था, तो मैं सिर्फ टीसीपी (या यूनिक्स) सॉकेट का उपयोग करता हूं। –

1

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