Unix/Linux提供了很多IPC:pipes, sockets, shared memory, dbus, message-queues...
哪些是最适合的应用程序,它们是如何执行的?
发布于 2017-12-26 15:50:00
以下是七大名单:
仅在与父/子进程相关的进程中有用。打电话pipe(2)
and fork(2)
...。单向的。
FIFO,或命名pipe
两个不相关的进程可以使用FIFO,不像普通管道。打电话mkfifo(3)
...。单向的。
双向的。用于网络通信,但也可以在本地使用。可用于不同的协议。TCP没有消息边界。打电话socket(2)
...
OS维护离散消息。见sys/msg.。H型...
信号向另一个进程发送整数。不适合多线程。打电话kill(2)
...
一种用于多进程或线程的同步机制,类似于排队等候浴室的人。见sys/sem.。H型...
执行您自己的并发控制。打电话shmget(2)
...
在选择一种方法而不是另一种方法时,一个决定因素是消息边界问题。您可能希望“消息”彼此之间是离散的,但它并不适用于TCP或管道之类的字节流。
考虑一对echo客户端和服务器。客户端发送字符串,服务器接收字符串并立即将其发送回来。假设客户端发送“Hello”、“Hello”和“应答如何?”
使用字节流协议,服务器可以接收为“Hell”、“oHelloHow”和“About a答案?”;或者更现实地说,“HelloHelloHow to a答案?”。服务器不知道消息边界在哪里。
一个古老的技巧是将消息长度限制在CHAR_MAX
或UINT_MAX
并同意在char
或uint
因此,如果您在接收方,您必须首先读取消息的长度。这也意味着一次只应该有一个线程进行消息读取。
对于像UDP或消息队列这样的离散协议,您不必担心这个问题,但是从编程上来说,字节流更容易处理,因为它们的行为就像文件和stdin/out。
发布于 2017-12-26 16:45:15
共享内存可能是最有效的,因为您在此基础上构建了自己的通信方案,但它需要大量的注意和同步。解决方案也可用于向其他计算机分发共享内存。
插座是当今最便携的,但需要比管道更高的开销。透明地在本地或网络上使用套接字是一项巨大的收获。
消息队列和信号对于硬实时应用程序来说是很好的,但它们不那么灵活。
这些方法自然是为进程之间的通信而创建的,在进程中使用多个线程可以使事情复杂化--特别是使用信号。
发布于 2017-12-26 17:42:24
下面是一个带有简单基准的网页:https://sites.google.com/site/rikkus/sysv-IPC-VS-Unix-Piets-VS-Unix-套接字
据我所知,每一个都有各自的优点:
https://stackoverflow.com/questions/-100000012
复制相似问题