c - 如果使用共享内存，进程是否仍然比线程有优势？

Question

我编写了一个 Linux 应用程序，其中主要的“消费者”进程 fork 出一堆“读取器”进程(~16)，这些进程从磁盘读取数据并将其传递给“消费者”以供显示。数据通过使用 socketpair 在 fork 之前创建的套接字传递。

我最初用这个进程边界写它有 3 个原因:

1. 消费者进程具有实时约束，因此我想避免在消费者中分配任何内存。读者可以随意分配内存，甚至可以用另一种语言编写(例如使用垃圾回收)，这不会中断具有 FIFO 优先级的消费者。此外，读取器进程中的磁盘访问或其他 IO 不会中断消费者。我认为使用线程无法获得此类保证。

2. 使用进程将阻止我这个程序员做一些愚蠢的事情，比如使用全局变量和破坏其他进程的内存。

3. 我认为 fork 出一堆 worker 是利用多 CPU 架构的最佳方式，而且我认为使用进程而不是线程通常会更安全。

并非所有阅读器都始终处于事件状态，但是，那些处于事件状态的阅读器会不断发送大量数据。最近我在想，要通过避免与写入和读取套接字相关的内存副本来优化这一点，最好将数据直接读入共享内存缓冲区 (shm_open/mmap)。然后只有这个共享内存的索引会通过套接字传递，消费者会直接从中读取，然后再将其标记为可用。

无论如何，进程相对于线程的最大好处之一是避免破坏另一个线程的内存空间。你认为切换到共享内存会破坏我在这个架构中的任何优势吗？在此上下文中使用进程是否还有任何优势，或者我应该将我的应用程序切换为使用线程？

Answer 1

您认为线程无法满足实时约束的假设是错误的。只要消费者线程不使用 malloc 本身(这当然会导致锁争用)，读取线程中的 IO 或内存分配就不能停止消费者线程。我会推荐阅读什么 POSIX如果您不确定，必须就此事发表意见。

至于使用进程而不是线程的其他原因(安全性、用不同语言编写读者的可能性等)，这些都是完全合理的。只要您的消费者进程将共享内存缓冲区视为潜在不安全的外部数据，我认为您不会因为从管道切换到共享内存而失去任何重要的安全性。