누구나 java.lang.Thread의 join() 멤버가 그렇게 명명 된 이유를 알고 있습니까? 그 javadoc는 다음과 같습니다 :java.lang.Thread.join() 메서드는 왜 그렇게 명명 되었습니까?
이 스레드가 죽을 때까지 기다립니다.
일부 스레드 호출 스레드에서 조인을 호출하면 다른 스레드 호출 스레드가 죽어서 실행을 계속할 때까지 대기합니다. 아마도 스레드를 호출하는 것은 물론 죽을 것이지만 여전히 저자가이 이름을 사용한 이유는 확실하지 않습니다.
기본적으로 실행중인 호출 스레드가 주어진 실행 상태에 참여하기를 기다리고 있기 때문에이 이름이 지정됩니다. 또한 posix 및 다른 많은 스레딩 패키지에서 join이라는 이름입니다.
join 호출이 중단 된 후 (중단되지 않은 경우) 두 개의 실행 스레드가 기본적으로 그 지점에서 실행됩니다 (해당 스레드가 현재 종료 된 스레드의 반환 값을 얻음).
"주어진 상태의 실행에 참여하기를 기다리는 것보다"호출하는 스레드가 "두 개의 스레드를 하나로 합칩니다"라는 말보다 더 좋을 것입니다. 따라서 아무 것도 수행하지 않는 논리적 인 스레드가 하나 뿐이므로, 그 시점까지 독립적 인 두 사람 대신에. 아직 그 표현에 100 % 만족하지는 못합니다. – Adam
실행중인 다른 스레드 (예 : 가입하려는 스레드)가 현재 스레드 (즉, 호출중인 스레드)에 가입 (즉, 죽기) 할 때까지 기다리고 있기 때문입니다.
호출 스레드가 죽지 않습니다. 단순히 다른 스레드가 그렇게 할 때까지 대기합니다.
제어 흐름이 동시 스레드로 분할 될 때 동시 소프트웨어 모델링에서 유래합니다. 나중에 두 실행 스레드가 다시 참여하게됩니다.
또한 waitToDie()은 아마도 너무 길었고 b) 너무 병적이었습니다.
아, 이제 더 이해가됩니다. 또한 wait()도 옵션이 될 수 있습니다 ... –
이것은 명명법 뒤에 진짜 이유가되어야합니다 –
이 용어는 널리 사용되는 용어입니다 (Java 이외에도). 나는 그것을 어떤 식 으로든 다른 스레드와 연결시키는 일종의 것으로 생각합니다. 나는 Thread.Associate()가 더 나은 선택이 될 수 있다고 생각하지만 Join()은 나쁘지 않다.
저에게 Thread.associate()는 호출을 넘어서 두 스레드 간의 연결을 암시하지만 별도의 개체. 주어진 스레드가 더 이상 실행되지 않아 오히려 오해의 소지가 있다고 생각합니다. 그러나 join() 호출로 정의 된대로 단일 실행 경로로 결합하는 것이 좋습니다. –
글쎄 ... 이건 정말 맞지는 않지만 "대기실"(실제로는 FIFO, HRRN 등의 특정 일정이있는 대기열이 아닙니다)을 생각했습니다. 스레드가 계속 진행할 수없고 다른 스레드가 스레드를 기다려야 기다릴 필요가있을 때 대기실의 사람들 (일명 스레드)이 다음에 활동을 시작하게됩니다 ...
결합이 정확히 직관적이지 않다고 생각되면, System.Threading.Thread.Join()에 대한 독일어 MSDN 문서를 읽으십시오. 그것은 "결합"이 아닌 "링크"를 의미하는 "verknüpfen"으로 번역됩니다. 음, 적어도 문서는 스레드가 끝날 때까지 기다리는다고 말합니다 (죽기보다는); – OregonGhost
글쎄, "verknüpfen"은 "매듭"입니다. 그래서 저는 그들이 "스레드"메타포로 도움이 되고자한다고 생각합니다. * 시도 *에 중점을 둡니다. – Zarkonnen
아마도. 그러나 소프트웨어 개발 용어에서 "verknüpfen"은 항상 "링크"(하이퍼 링크 또는 셸 링크 에서처럼)로 사용되므로 다소 나쁜 선택입니다. 그러나 MSDN의 독일어 번역본에는 그 중 많은 부분이 포함되어 있습니다. 때로는 번역사가 기술 부분에 대해 충분히 알지 못하는 것 같습니다.이전 버전에서는 "참조"가 맹목적으로 "Verweis"로 번역되었지만 프로그래밍 언어로는 참조 용이지만 독일어로는 이해할 수없는 참조 문서 용으로도 번역되었지만 ... ;) – OregonGhost