螺纹连接的起源
几乎所有支持线程的编程语言都有一个名为 join 的方法。我了解 join 的作用，但想知道它的命名背后的起源是什么？像 finish 这样的名称不是更合适吗？
Nearly all programming languages that support threading, have a method called join. I understand what a join does, but would like to know what the origin behind the naming of it is? Wouldn't a name such as finish be more appropriate?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我认为这是来自执行路径的类比。当线程产生时，程序的执行路径分成两个单独的路径，现在您希望这两个路径再次连接回单个路径。
I think it comes from the analogy of execution paths. The program's execution path split into two separate paths when the thread was spawned, and now you want the two paths to join back together into a single path again.
线程 A 和线程 B 做了不同的事情，现在它们将要重新结合，因为它们的结果必须交换——它们将相互结合，继续下去，最终再次分裂。
Thread A and Thread B did different things and now they are going to kind of reunite because their results have to get exchanged - they will join each other, go on and eventually split up again.
据我理解/解释（尽管如果我错了请纠正我），执行线程都应该有助于单个总体任务（如果线程之间没有交互，那么它们也可能是单独的进程，毕竟其中之一线程的要点是克服进程之间的通信障碍）。因此，子任务从整体任务中分支出来，然后在稍后的时间点重新加入，而不是陷入死胡同，这似乎是合乎逻辑的。另外，当创建一个线程时，它会被分配一些其父级资源，即使该线程不返回值，它仍然应该返回最初给出的值，从而与原始线程合并或“加入” 。
As I understand/interpret it (although correct me if I'm wrong), threads of execution should all contribute towards a single overall task (if there is no interaction between threads, then they might as well be separate processes, after all one of the main points of threading is to overcome the communication barrier between processes). Therefore it seems logical that subtasks branch off from the overall task and then re-join at a later point, rather than running into a dead end. Also, seeing as when a thread is created it is allocated some of its parents resources, even if the thread does not return a value it should still return what it was given in the first place, thus merging or "joining" with the original thread.