我们仍然处于项目的设计阶段，但我们正在考虑在嵌入式Linux内核上有三个独立的进程。其中一个过程是通信模块，它通过各种介质处理与设备之间的所有通信。
其他两个进程需要能够通过通信过程发送/接收消息。我正在尝试评估Linux提供的IPC技术;其他进程将发送的消息大小各不相同，从调试日志到流媒体，速率约为5 Mbit。此外，媒体可以同时流入和流出。
您对此应用建议使用哪种IPC技术？ http://en.wikipedia.org/wiki/Inter-process_communication
处理器运行大约400-500 Mhz，如果这改变了什么。 不需要跨平台，只有Linux才行。 需要在C或C ++中实现。
答案 0 :(得分：60)
选择IPC时，应考虑性能差异的原因，包括传输缓冲区大小，数据传输机制，内存分配方案，锁定机制实现，甚至代码复杂性。
在可用的IPC机制中，性能选择通常归结为Unix domain sockets或named pipes (FIFOs)。我在Performance Analysis of Various Mechanisms for Inter-process Communication上阅读了一篇文章，指出IPC的Unix域套接字可以提供最佳性能。我看到了相互矛盾的结果elsewhere，表明管道可能更好。
在发送少量数据时，我更喜欢命名管道（FIFO）。这需要一对用于双向通信的命名管道。 Unix域套接字需要更多的开销来设置（套接字创建，初始化和连接），但更灵活，可以提供更好的性能（更高的吞吐量）。
您可能需要为特定的应用程序/环境运行一些基准测试，以确定最适合您的方法。根据提供的描述，听起来像Unix域套接字可能是最合适的。
Beej's Guide to Unix IPC 适合开始使用Linux / Unix IPC。
答案 1 :(得分：30)
我会选择Unix域套接字：比IP套接字更少的开销（即没有机器间通信），但同样方便。
答案 2 :(得分：16)
无法相信没有人提到过dbus。
http://www.freedesktop.org/wiki/Software/dbus
http://en.wikipedia.org/wiki/D-Bus
如果你的应用程序架构简单，在这种情况下 - 在一个性能至关重要的受控嵌入式环境中 - 你无法击败共享内存，可能会有点过头了。
答案 3 :(得分：11)
如果性能确实成为一个问题，你可以使用共享内存 - 但它比其他方法复杂得多 - 你需要一个信令机制来表示数据准备就绪（信号量等）以及锁定以防止并发在修改结构时访问结构。
好处是你可以传输大量数据而无需将其复制到内存中，这肯定会在某些情况下提高性能。
也许有可用的库通过共享内存提供更高级别的原语。
共享内存通常是通过使用MAP_SHARED（如果你不希望它持久化，可以在tmpfs上）对同一文件进行mmaping来获得的;很多应用程序也使用System V共享内存（恕我直言，因为愚蠢的历史原因;它是一个不太好的接口，同样的东西）
答案 4 :(得分：4)
在撰写本文时（2014年11月），Kdbus和Binder离开了Linux内核的登台分支。目前还无法保证要么进入，但前景对两者都有利。 Binder是Android中的轻量级IPC机制，Kdbus是内核中类似dbus的IPC机制，它减少了上下文切换，从而大大加快了消息传递。
还有＆＃34;透明的进程间通信＆＃34;或者TIPC，它非常强大，可用于聚类和多节点设置; http://tipc.sourceforge.net/
答案 5 :(得分：0)
Unix域套接字将满足您的大多数IPC要求。在这种情况下，由于内核提供了此IPC工具，因此您实际上不需要专用的通信过程。另外，请查看POSIX消息队列，我认为它是Linux中利用率最差的IPC之一，但在需要n：1通信的许多情况下非常方便。