进程通信与线程间通信 1.docVIP

进程通信和线程间通信 1 进程通信和线程间通信(1)2010-04-09 15：32进程间通信与线程间通信Linux下进程间通信(IPC)的方式数不胜数，光UNPv2列出的就有：pipe、FIFO、POSIX消息队列、共享内存、信号(signals)等等，更不必说Sockets了。同步原语(synchronization primitives)也很多，互斥器(mutex)、条件变量(condition variable)、读写锁(reader-writer lock)、文件锁(Record locking)、信号量(Semaphore)等等。 如何选择呢?根据我的个人经验，贵精不贵多，认真挑选三四样东西就能完全满足我的工作需要，而且每样我都能用得很熟,，不容易犯错。 5进程间通信进程间通信我首选Sockets(主要指TCP，我没有用过UDP，也不考虑Unix domain协议)，其最大的好处在于：可以跨主机，具有伸缩性。反正都是多进程了，如果一台机器处理能力不够，很自然地就能用多台机器来处理。把进程分散到同一局域网的多台机器上，程序改改host：port配置就能继续用。相反，前面列出的其他IPC都不能跨机器(比如共享内存效率最高，但再怎么着也不能高效地共享两台机器的内存)，限制了scalability。 在编程上，TCP sockets和pipe都是一个文件描述符，用来收发字节流，都可以read/write/fcntl/select/poll等。不同的是，TCP是双向的，pipe是单向的(Linux)，进程间双向通讯还得开两个文件描述符，不方便；而且进程要有父子关系才能用pipe，这些都限制了pipe的使用。在收发字节流这一通讯模型下，没有比sockets/TCP更自然的IPC了。当然，pipe也有一个经典应用场景，那就是写Reactor/Selector时用来异步唤醒select(或等价的poll/epoll)调用(Sun JVM在Linux就是这么做的)。 TCP port是由一个进程独占，且操作系统会自动回收(listening port和已建立连接的TCP socket都是文件描述符，在进程结束时操作系统会关闭所有文件描述符)。这说明，即使程序意外退出，也不会给系统留下垃圾，程序重启之后能比较容易地恢复，而不需要重启操作系统(用跨进程的mutex就有这个风险)。还有一个好处，既然port是独占的，那么可以防止程序重复启动(后面那个进程抢不到port，自然就没法工作了)，造成意料之外的结果。 两个进程通过TCP通信，如果一个崩溃了，操作系统会关闭连接，这样另一个进程几乎立刻就能感知，可以快速failover。当然，应用层的心跳也是必不可少的，我以后在讲服务端的日期与时间处理的时候还会谈到心跳协议的设计。 与其他IPC相比，TCP协议的一个自然好处是可记录可重现，tcpdump/Wireshark是解决两个进程间协议/状态争端的好帮手。 另外，如果网络库带连接重试功能的话，我们可以不要求系统里的进程以特定的顺序启动，任何一个进程都能单独重启，这对开发牢靠的分布式系统意义重大。 使用TCP这种字节流(byte stream)方式通信，会有marshal/unmarshal的开销，这要求我们选用合适的消息格式，准确地说是wire format。这将是我下一篇blog的主题，目前我推荐Google Protocol Buffers。 有人或许会说，具体问题具体分析，如果两个进程在同一台机器，就用共享内存，否则就用TCP，比如MS SQL Server就同时支持这两种通信方式。我问，是否值得为那么一点性能提升而让代码的复杂度大大增加呢?TCP是字节流协议，只能顺序读取，有写缓冲；共享内存是消息协议，a进程填好一块内存让b进程来读，基本是停等方式。要把这两种方式揉到一个程序里，需要建一个抽象层，封装两种IPC。这会带来不透明性，并且增加测试的复杂度，而且万一通信的某一方崩溃，状态reconcile也会比sockets麻烦。为我所不取。再说了，你舍得让几万块买来的SQL Server和你的程序分享机器资源吗?产品里的数据库服务器往往是独立的高配置服务器，一般不会同时运行其他占资源的程序。 TCP本身是个数据流协议，除了直接使用它来通信，还可以在此之上构建RPC/REST/SOAP之类的上层通信协议，这超过了本文的范围。另外，除了点对点的通信之外，应用级的广播协议也是非常有用的，可以方便地构建可观可控的分布式系统。 本文不具体讲Reactor方式下的网络编程，其实这里边有很多值得注意的地方，比如带back off的retry connecting，用优先队列来组织timer等等，留作以后分析吧。 6线程间同步线程同步的四项原则，按重要性