有一个精灵进程A，用于从特定设备接收和处理数据；有一个控制进程B，用于对设备进行控制。要求在控制进程B启动后,精灵进程A停止对设备数据的接收(由于设备设计原因必须停止收),B退出后A恢复接收。精灵进程A是长期运行的，B则只在需要时启动。这就必然要求A，B之间的通讯。由于大部分时间B都不处于运行状态，出于性能需要，我们不希望A在探测B是否运行时花太多的开销，那么应该使用什么通讯方式好呢？请大虾指教

楼上的是可以的，我有另一种想法：
精灵进程A 启一个socket线程
控制进程B 启动的时候来进行连接，将需要停止的设备信息发给A

这样可以避免 A 长时间的查询 B的状态，只要等待socket连接即可

B进程启动后先将设备号写入共享内存（什么管道，文件，消息队列等等都行），然后给A发送信号。A收到信号后读取共享内存获得设备号即可。

不需要多线程，注册一个信号处理函数即可。不过从模块的耦合性角度来说，赞同你的socket方法。

这个问题，不能片面的站在IPC技术实现角度考虑。容易考虑不清楚，所谓站得高才看得远。这实际上是个对资源的抢占问题。B进程具有较高的优先级，就可以抢占A占用的任一资源。用完再归还给A("用"和"接收数据"在抽象上来讲是一样的).能最好的契合这一模型的IPC方式就是最好的选择。

而抢占这一行为需要仲裁。所以我认为最好的模型就是你还需要第三个进程仲裁者C。由它决定A,B的运行行为,A,B都同C进行通信。平时他们都可以处在休眠状态，如select/sleep/lock住等。 至于具体通信方式任何一种都行。这仅仅是具体情况下的需求。若你想分布于多台计算机，那用socket。若位于同一台机器，你可以选择IPC的所有方式（从通信速率角度，shm,pipe,message que,fmap,socket依次递减，但相对于你的应用基本可以忽略不计）。signal方式我觉得不好。虽然32以后的实时信号是可以携带附加信息的。但由于你的应用有慢系统调用，信号方式的处理可能变得很复杂（因为你可能需要恢复被中断的系统调用，和可重入系统调用的同步问题），而且这样的代码也不可移植，众所周知，不同的系统的有些信号语义不同。

倾向于使用本地socket通讯，起始socket通讯很简单，就是对本地临时文件进行操作，但它很灵活，从B接收到的数据， 要干什么，针对谁，都可以通过定义通讯格式来处理。