使用哪种Linux IPC技术?

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

其他两个进程将需要能够通过通信过程发送/接收消息。 我正在评估Linux提供的IPC技术; 其他进程将发送的消息大小也不相同,从debugging日志到大约5 Mbit速率的stream媒体。 而且,媒体可以同时stream入和stream出。

你会为这个应用程序build议哪种IPC技术? http://en.wikipedia.org/wiki/Inter-process_communication

处理器运行在400-500兆赫左右,如果这改变了一切。 不需要跨平台,Linux才行。 在C或C ++中的实现是必需的。

我会去的Unix域套接字:比IP套接字(即没有机间通信)更less的开销,但相同的便利,否则。

selectIPC时,应考虑性能差异的原因,包括传输缓冲区大小,数据传输机制,内存分配scheme,locking机制实现,甚至代码复杂性。

在可用的IPC机制中,性能的select通常归结为Unix域套接字或命名pipe道(FIFOs) 。 我读了一篇关于进程间通信的各种机制的性能分析的论文,指出IPC的Unix域套接字可以提供最好的性能。 我看到别处有矛盾的结果表明pipe道可能会更好。

在发送less量数据时,我更喜欢命名pipe道(FIFOs)。 这需要一对命名pipe道进行双向通信。 Unix域套接字在安装(套接字创build,初始化和连接)方面需要更多的开销,但是更灵活,可以提供更好的性能(更高的吞吐量)。

您可能需要针对您的特定应用程序/环境运行一些基准testing,以确定哪些最适合您。 从提供的描述中,听起来像Unix域套接字可能是最合适的。


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

不敢相信没有人提到dbus。

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

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

如果您的应用程序在结构上很简单,那么在性能至关重要的受控embedded式环境中,您可能无法打败共享内存。

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

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

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

共享内存通常是通过使用MAP_SHARED(如果你不想保存的话可以在tmpfs上)压缩同一个文件来获得的。 许多应用程序也使用System V共享内存(恕我直言,愚蠢的历史原因,这是一个不太好的接口,同样的事情)

有关“经典”Linux IPC机制的评论,请看这里 。

在撰写本文时(2014年11月),Kdbus和Binder离开了linux内核的升级分支。 目前还没有保证要么能够进入,但两者的前景都是有利的。 Binder是Android中的一个轻量级的IPC机制,Kdbus是内核中类似dbus的IPC机制,它减less了上下文切换,从而大大加快了消息传递速度。

还有“透明的进程间通信”或TIPC,这对于群集和多节点设置是强大的,是有用的; http://tipc.sourceforge.net/