Почему метод java.lang.Thread.join () был назван так?

Question

Кто-нибудь знает, почему метод join () члена java.lang.Thread был назван так? Его Javadoc:

Ожидает смерти этой нити.

Когда в одном потоке вызывается соединение, вызывающий поток ожидает, пока другой не умрет и продолжит выполнение. Предположительно вызывающий поток тоже умрет, но все же неясно, почему автор использовал это имя.

Answer 1

Это обычное имя в многопоточности - не то, чтобы Java использовало его первым. (Например, это то, что pthreads также использует.)

Полагаю, вы могли бы представить, что двое людей гуляют - вы присоединяетесь к другому и гуляете с ними, пока не закончите, прежде чем вернуться к тому, что вы делали. Эта сортировка аналогии, возможно, была первоначальной причиной, хотя я согласен, что она не совсем интуитивна.

Answer 2

Он назван так, потому что вы в основном утверждаете, что вызывающий поток выполнения будет ждать, чтобы присоединиться к данному состоянию выполнения. Он также называется join in posix и многими другими пакетами потоков.

После того, как этот вызов объединения возвращается (если он не был прерван), два потока выполнения в основном работают вместе с этой точки (причем этот поток получает возвращаемое значение потока, завершившегося сейчас).

Answer 3

Это происходит из параллельного моделирования программного обеспечения, когда поток управления разделяется на параллельные потоки. Позже два потока выполнения снова соединятся.

Также waitToDie() было, вероятно, а) слишком длинным и б) слишком болезненным.

Answer 4

хорошо ... это не совсем правильно, но я подумал о "комнате ожидания" (на самом деле это не очередь с определенным расписанием, таким как FIFO, HRRN или тому подобное). когда поток не может продолжаться и ему нужно ждать какого-то другого потока, чтобы завершить его, он просто присоединяется к ребятам (или потокам) в комнате ожидания, чтобы стать активным ...

Answer 5

Это широко используемая терминология (также за пределами Java). Я воспринимаю это как своего рода «Связывание потока с другим» каким-то образом. Я думаю, что Thread.Associate () мог бы быть лучшим вариантом, но Join () также неплох.

Answer 6

Поскольку вы ожидаете, что другой поток выполнения (то есть тот, на котором вы вызываете соединение) присоединится (то есть умрет) к текущему (то есть вызывающему) потоку.

Вызывающий поток не умирает: он просто ждет, пока другой поток сделает это.