来自https://computing.llnl.gov/tutorials/pthreads/：
加入线程可以匹配一个pthread_join（）调用。在同一个线程上尝试多个连接是一个逻辑错误。
也来自＆＃34; man pthread_join＆＃34;：
如果多个线程同时尝试使用同一个线程加入，则结果是未定义的。
但是，从程序员的角度来看，多个线程可能希望等待单个线程完成（类似于障碍），这是完全合理的。
例如，我们可能有thread1，thread2独立运行，我们可能希望两个线程都等到thread3完成。
这种限制背后有任何技术原因吗？
答案 0 :(得分：5)
我认为技术原因是 pthread_join 是一个POSIX标准，对于多线程，它试图只为实现者指定必要的原语。任何更丰富的语义都会带来更昂贵的实现，也可能是更难的API。
实际上，POSIX已经认为这个函数是一个方便而不是原始的，支持一个非常非常常见的用例：一个线程等待另一个线程的终止。
POSIX.1-2008 pthread_join RATIONALE的第一段有点冗长，但却有许多相关的观察结果：
pthread_join（）函数是一种在多线程应用程序中证明非常有用的便利。确实，如果没有通过将额外状态作为参数的一部分传递给 start_routine（），程序员可以模拟此函数。终止线程将设置一个标志以指示终止并广播属于该状态的条件;连接线程将等待该条件变量。虽然这种技术允许线程在更复杂的条件下等待（例如，等待多个线程终止），但是等待单个线程终止被认为是非常有用的。此外，包括 pthread_join（）函数决不会妨碍程序员编写这样复杂的等待。因此，虽然在这个POSIX.1-2008卷中没有原语，包括 pthread_join（），但被认为是有价值的。
答案 1 :(得分：0)
Posix pthreads和Windows Kernel Objects之间存在巨大差异（我公然假设您熟悉它）。我发现它有不愉快的限制，你只提到了一个。除了当前的实现细节之外，没有真正的技术原因（是的，加入后线程状态不会保留在内存中，但为什么？）。另一个非常令人不快的限制是在一次调用中缺少连接多个线程的可能性 - 这会在线程上进行多路复用。
尽管如此，每天仍有数百万个基于pthread的程序运行，所以这些限制并不是一个显示阻止。但实际上，没有这些任务，某些任务会更容易执行。