2010-02-17 20 views
57

हम अभी भी हमारे प्रोजेक्ट के डिजाइन चरण में हैं लेकिन हम एक एम्बेडेड लिनक्स कर्नेल पर तीन अलग प्रक्रियाओं के बारे में सोच रहे हैं। एक प्रक्रिया मॉड्यूल के साथ प्रक्रियाओं में से एक जो विभिन्न माध्यमों के माध्यम से डिवाइस से और सभी संचारों को संभालती है।कौन सी लिनक्स आईपीसी तकनीक का उपयोग करना है?

अन्य दो प्रक्रियाओं को संचार प्रक्रिया के माध्यम से संदेश भेजने/प्राप्त करने में सक्षम होना आवश्यक होगा। मैं लिनक्स प्रदान करता आईपीसी तकनीकों का मूल्यांकन करने की कोशिश कर रहा हूं; जिस संदेश को अन्य प्रक्रियाएं भेजी जाएंगी, वह डीबग लॉग से स्ट्रीमिंग मीडिया तक ~ 5 एमबीटी दर पर आकार में भिन्न हो जाएगी। साथ ही, मीडिया एक साथ स्ट्रीमिंग और आउट हो सकता है।

इस एप्लिकेशन के लिए आप कौन सी आईपीसी तकनीक सुझाएंगे? http://en.wikipedia.org/wiki/Inter-process_communication

प्रोसेसर 400-500 मेगाहट्र्ज के आसपास चल रहा है अगर यह कुछ भी बदलता है। क्रॉस-प्लेटफॉर्म होने की आवश्यकता नहीं है, लिनक्स केवल ठीक है। सी या सी ++ में कार्यान्वयन की आवश्यकता है।

+23

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

+2

@enthusiasticgeek डी-बस पूरी तरह से उपयोगकर्तास्थान में किया जाता है। कुछ कर्नेल लोग [kdbus] (https://github.com/gregkh/kdbus) पर काम कर रहे हैं लेकिन यह अभी भी एक काम प्रगति पर है। – new123456

+0

एक arm926ejs 200MHz प्रोसेसर पर, एक विधि कॉल और दो uint32 तर्कों के साथ उत्तर 0 से 15 एमएस के बीच कहीं भी खपत करता है। औसत 6 एमएस अन्य प्रोसेसर पर अन्य लोग कैसे देखते हैं? – minghua

उत्तर

27

मैं यूनिक्स डोमेन सॉकेट के लिए जाऊंगा: आईपी सॉकेट से कम ओवरहेड (यानी कोई इंटर-मशीन कॉम नहीं) लेकिन अन्यथा समान सुविधा।

6

"क्लासिक" लिनक्स आईपीसी तंत्र की समीक्षा के लिए: here देखें।

52

अपने आईपीसी का चयन करते समय आपको स्थानांतरण बफर आकार, डेटा स्थानांतरण तंत्र, स्मृति आवंटन योजनाओं, लॉकिंग तंत्र कार्यान्वयन, और यहां तक ​​कि कोड जटिलता सहित प्रदर्शन अंतरों के कारणों पर विचार करना चाहिए।

उपलब्ध आईपीसी तंत्रों में, प्रदर्शन के लिए विकल्प अक्सर Unix domain sockets या named pipes (FIFOs) पर आता है। मैंने Performance Analysis of Various Mechanisms for Inter-process Communication पर एक पेपर पढ़ा जो इंगित करता है कि आईपीसी के लिए यूनिक्स डोमेन सॉकेट सर्वश्रेष्ठ प्रदर्शन प्रदान कर सकता है। मैंने विरोधाभासी परिणाम elsewhere देखा है जो इंगित करता है कि पाइप बेहतर हो सकते हैं।

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

आपको यह निर्धारित करने के लिए अपने विशिष्ट एप्लिकेशन/पर्यावरण के लिए कुछ मानक चलाने की आवश्यकता हो सकती है कि आपके लिए सबसे अच्छा क्या काम करेगा। प्रदान किए गए विवरण से, ऐसा लगता है जैसे यूनिक्स डोमेन सॉकेट सबसे अच्छा फिट हो सकता है।


Beej's Guide to Unix IPC लिनक्स/यूनिक्स आईपीसी के साथ शुरू हो रही है के लिए अच्छा है।

11

यदि प्रदर्शन वास्तव में एक समस्या बन जाता है तो आप साझा स्मृति का उपयोग कर सकते हैं - लेकिन यह अन्य तरीकों की तुलना में बहुत अधिक जटिल है - आपको सिग्नलिंग तंत्र की आवश्यकता होगी ताकि यह संकेत हो सके कि डेटा तैयार है (सेमफोर इत्यादि) साथ ही ताले को रोकने के लिए संशोधित होने पर संरचनाओं के समवर्ती उपयोग।

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

शायद उपयोग योग्य पुस्तकालय हैं जो साझा स्मृति के माध्यम से उच्च स्तरीय प्राइमेटिव प्रदान करते हैं।

साझा स्मृति आम तौर पर MAP_SHARED का उपयोग करके उसी फ़ाइल को mmaping द्वारा प्राप्त की जाती है (जो एक tmpfs पर हो सकता है यदि आप इसे जारी नहीं रखना चाहते हैं); बहुत से ऐप्स सिस्टम वी साझा मेमोरी का उपयोग करते हैं (बेवकूफ ऐतिहासिक कारणों के लिए आईएमएचओ; यह एक ही चीज़ के लिए बहुत कम अच्छा इंटरफ़ेस है)

15

विश्वास नहीं कर सकता कि किसी ने भी डीबीस का उल्लेख नहीं किया है।

http://www.freedesktop.org/wiki/Software/dbus

http://en.wikipedia.org/wiki/D-Bus

शीर्ष पर एक सा हो सकता है आपके आवेदन वास्तुकला सरल है, ऐसी स्थिति में - एक नियंत्रित एम्बेडेड वातावरण जहां प्रदर्शन महत्वपूर्ण है में - आप साझा स्मृति हरा सकते हैं।

+3

डीबीस के पास एम्बेडेड वातावरण में प्रदर्शन समस्याएं हैं। यह बहुत सारे संदर्भ स्विचिंग बनाता है क्योंकि आप dbus के माध्यम से एक संदेश बनाते हैं, इसे कर्नेल को भेजें, फिर इसे वापस dbus पर भेजें। एक पैच है जो एक नए सॉकेट प्रकार का उपयोग करके इन संदर्भ स्विच को कम करता है, जिसे AF_BUS कहा जाता है, लेकिन Red Hat ने किसी कारण से पैच लागू नहीं किया है। – jeremiah

+4

कई संदर्भ स्विचों का यह डिज़ाइन एक सेवा खोज बस होने के लिए डीबीस के मूल लक्ष्य को इंगित करता है, न कि आईपीसी तंत्र। – jeremiah

+0

@jeremiah: एम्बेडेड वातावरण_ में _performance समस्याओं के बारे में कोई विशिष्टता? मैंने कुछ प्रोफाइलिंग और ऑनलाइन शोध किया, एक गंभीर मुद्दा नहीं दिख रहा है। [यहां] देखें (http://stackoverflow.com/questions/25085727/what-dbus-performance-issue-could-prevent-it-from-embedded-system) – minghua

4

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

"पारदर्शी इंटर-प्रोसेस संचार" या टीआईपीसी भी है, जो मजबूत है, क्लस्टरिंग और बहु-नोड सेट अप के लिए उपयोगी है; सिग्नल, बेनामी पाइप्स, नाम पाइप्स या FIFOs, SysV संदेश कतार, POSIX संदेश कतार, SysV साझा स्मृति, POSIX साझा स्मृति, SysV संकेतबाहु: http://tipc.sourceforge.net/

संबंधित मुद्दे