我正试图找出线程间和进程间通信之间是否存在固有的速度差异。
我知道,当使用线程时,线程共享相同的内存,可以使用相同的全局变量,而进程必须使用其他技巧,这基本上意味着队列。
但以以下情况为例:
应用程序由几个完全独立的.exe
文件组成。当所有这些都运行时,它们形成了生产者/消费者(或发布者/订阅者(体系结构,一些进程产生一些值,其他进程读取和使用这些值,可能产生一些其他值。
这种通信是用IPC的传统方式完成的。
我的问题是:如果我移动代码,使其成为一个具有多个线程的进程(假设与变量名等没有冲突(,但保持通信方法不变,队列后面有所有的锁和信号量,那么基于线程的应用程序会比基于进程的应用程序更快吗?
进程与线程的启动成本并不重要,因为应用程序要运行很长时间(小时(,所以几毫秒并不重要。
谷歌还没有对此给出确切的答案。
澄清问题的某些方面:
-
我想要最大化的因素是吞吐量。
一些外部因素(例如arduino传感器(为其中一个节点产生输入,整个网络需要一些时间,而所有节点都消耗并产生值。然后可以处理新的输入。我希望能够每分钟/秒处理更多的输入。
-
来回传递的数据大多是数字或数字的小数组。
-
整个网络可以具有5到25个节点。
-
至于平台(如果它是相关的(,我想要Linux和Windows的答案。
-
具体的用例太大,无法在这里进行描述,因此请考虑上面提供的用例。就我自己而言,这既是一个关于特定问题的问题,也是一个教育问题。
请询问我在此未包含的任何其他相关信息。
如果我移动代码,使其成为一个具有多个线程的进程(假设与变量名等没有冲突(,但保持通信方法不变,队列中有所有的锁和信号量,基于线程的应用程序会比基于进程的应用程序更快吗?
这是不可能的。多线程版本会利用共享内存空间,而多进程版本则不能这样做。例如,你可以在一个线程中获取一个普通对象,并通过另一个线程的指针访问它,所有引用的子对象都会"只是工作";。任何未修改的内容都可以在一个线程中像在另一个线程一样轻松地访问,而无需付出特别的努力。
这根本无法跨进程运行,因为它们不共享地址空间。