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