使用哪种Linux IPC技术?

Ris*_*hiD 67 linux ipc

我们仍处于项目的设计阶段,但我们正在考虑在嵌入式Linux内核上有三个独立的进程.其中一个过程是通信模块,它通过各种介质处理与设备之间的所有通信.

其他两个进程需要能够通过通信过程发送/接收消息.我正在尝试评估Linux提供的IPC技术; 其他进程将发送的消息大小各不相同,从调试日志到流媒体,速率约为5 Mbit.此外,媒体可以同时流入和流出.

您对此应用建议使用哪种IPC技术? http://en.wikipedia.org/wiki/Inter-process_communication

处理器运行大约400-500 Mhz,如果这改变了什么.不需要跨平台,只有Linux才行.需要使用C或C++实现.

jsc*_*ier 63

选择IPC时,应考虑性能差异的原因,包括传输缓冲区大小,数据传输机制,内存分配方案,锁定机制实现,甚至代码复杂性.

在可用的IPC机制中,性能的选择通常归结为Unix域套接字命名管道(FIFO).我读了一篇关于进程间通信的各种机制的性能分析的文章,表明IPC的Unix域套接字可以提供最佳性能.我在其他地方看到了相互矛盾的结果,表明管道可能更好.

在发送少量数据时,我更喜欢命名管道(FIFO).这需要一对用于双向通信的命名管道.Unix域套接字需要更多的开销来设置(套接字创建,初始化和连接),但是更灵活并且可以提供更好的性能(更高的吞吐量).

您可能需要为特定的应用程序/环境运行一些基准测试,以确定最适合您的方法.根据提供的描述,听起来像Unix域套接字可能是最合适的.


Beej的Unix IPC指南适用于Linux/Unix IPC入门.


jld*_*ont 30

我会选择Unix域套接字:比IP套接字更少的开销(即没有机器间通信),但同样方便.


Dip*_*ick 18

不敢相信没有人提到过dbus.

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

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

如果您的应用程序在架构上很简单,那么可能会有点过头了 - 在这种情况下 - 在性能至关重要的受控嵌入式环境中 - 您无法击败共享内存.

  • Dbus在嵌入式环境中存在性能问题.它会创建大量的上下文切换,因为您通过dbus创建消息,将其发送到内核,然后将其发送回dbus.有一个补丁使用一个名为AF_BUS的新套接字类型减少了这些上下文切换,但Red Hat由于某种原因没有应用补丁. (4认同)
  • 许多上下文切换的这种设计指向dbus作为服务发现总线而不是IPC机制的最初目标. (4认同)

Mar*_*rkR 11

如果性能确实成为一个问题,你可以使用共享内存 - 但它比其他方法复杂得多 - 你需要一个信令机制来表示数据准备就绪(信号量等)以及锁定以防止并发访问结构而他们正在被修改.

好处是你可以传输大量数据而无需将其复制到内存中,这肯定会在某些情况下提高性能.

也许有可用的库通过共享内存提供更高级的原语.

共享内存通常是通过使用MAP_SHARED(如果你不希望它持久化,可以在tmpfs上)对同一文件进行mmaping来获得的; 很多应用程序也使用System V共享内存(恕我直言,因为愚蠢的历史原因;它是一个不太好的接口,同样的东西)