何时使用分叉或线程？ [关闭]答案

【问题标题】：When to use forking or threading? [closed]何时使用分叉或线程？ [关闭]
【发布时间】：2015-01-13 07:45:22
【问题描述】：

我有以下问题陈述：

实现一个函数 substLinesMany ... 。应同时处理所有指定的文件。如果任何文件导致错误，则 substLinesMany 将返回 false，否则返回 true。

你会在这里使用线程还是分叉？（必须选择一个）

【问题讨论】：

如果函数按照其名称的含义执行（更改文件中的行），并且文件位于同一个文件系统上，我不会使用任何一个。
就我个人而言，当涉及到信息交换时，我几乎总是会选择使用线程而不是分叉。不管怎样都行。
@JS1 线程可以返回有用的值吗？我试图从这个线程返回 500，它只打印 0：pastebin.com/raw.php?i=Hf10tgqR
@dgamma3 您将NULL 作为第二个参数传递给pthread_join。阅读文档。
void *status; int err, val; err = pthread_join(tid, &status); val = (uintptr_t) status; 如果您使用 pthread_join 的第二个参数，您传递给 pthread_exit 的 500 将作为 void * 传递给您。但我也采用了另一种方式，即 main 通过 pthread_create 中的参数将指针传递给每个线程，每个线程在退出之前将其数据复制到给定的指针。

【解决方案1】：

我会使用线程而不是分叉。创建一个新线程比创建一个新进程消耗更少的资源。线程共享相同的地址空间，而分叉一个进程需要创建一个具有新地址空间的新进程。鉴于函数的性质（替换文件中的行），没有必要为每个文件提供单独的地址空间。

唯一的缺点是，在使用线程时可能会遇到的同时打开文件的数量可能存在每个进程的限制。不过，这是一个可以解决的问题。

【讨论】：

【解决方案2】：

不同意见，以防万一。由于@CraigAnderson 提到的优势，线程似乎很诱人。

但不要忘记以下事实：

线程非常困难。共享内存意味着您必须使用锁等保护关键代码和数据部分。这是调试的噩梦。
轶事证据表明，在大多数情况下，您的并行解决方案会比顺序解决方案慢。原因：缓存未命中。内存比 CPU 慢很多。如果所有线程一直访问所有进程内存，那么所有 CPU 都会花费时间来刷新缓存。
fork 的开销比你想象的要少得多。 Linux 是写时复制，因此子进程从与父进程相同的物理内存页开始。只有更改的数据才会触发写入新的物理页面。
当您比较线程与分叉时，您隐含地假设一个 Unix 操作系统。线程在非 Unix 系统 (Windows) 上非常有用，在这些系统中，进程创建开销很大。
并行程序需要仔细设计，其中每个线程/进程仅在其自己的内存块上工作，以最大限度地减少缓存未命中。所以你会发现使用分叉和一些 Unix 流 IPC 非常有效，开销最小并且更容易调试。
Unix IPC 的语义，尤其是管道，提供了一种出色且易于使用的方式在进程之间进行通信。例如，来自工人子管道的read 会阻塞，直到结果可用。在父级中添加一个select 循环，您可以与一个简单的read 进行数据交换和同步。
线程的可移植性不如分叉。如果您使用 uClibc 库而不是 glibc 在多核嵌入式系统上工作，那么 uClibc 没有线程。

参考资料：

正如您在参考资料中看到的，他们都是大牌：ESR、Ousterhout、Larry Wall、Brendan Eich，StackOverflow 的创始人。比我聪明的多，还是怕死线。

【讨论】：

我希望看到“95% 的情况下并行解决方案比顺序解决方案慢”的参考。
线程很难？！在很多这个答案只是猜测（不是事实）
我查看了第一个和第三个参考文献 - 没有证据表明“95% 的情况下您的并行解决方案比顺序解决方案慢”。第二个参考是一本网上没有的书。
在 Wikipedia 上找到了这句话 - 似乎很恰当：“轶事证据被认为是对普遍主张的可疑支持”。
您的大部分主要关注点（第 1、2、5 点）适用于所有并行程序，而不仅仅是线程程序。老实说，很多听起来像FUD。并行性通常不是加快程序速度的正确答案，这可能是真的。但是当它是正确的答案时，它并不一定那么困难。这取决于您的线程/进程之间有多少交互性。但我同意你的看法，这会变得非常困难。