views:

628

answers:

6

Does anybody know why the method join() member of a java.lang.Thread was named like that? Its javadoc is:

Waits for this thread to die.

When join is called on some thread calling thread is waiting for the other to die and continue execution. Supposedly calling thread will die as well, but still it's not clear why the author used this name.

+7  A: 

It's a common name in threading - it's not like Java was the first to use it. (For example, that's what pthreads uses too.)

I guess you could imagine it like two people taking a walk - you join the other one and walk with them until you've finished, before going back to what you were doing. That sort of analogy may have been the original reason, although I agree it's not exactly intuitive.

Jon Skeet
+1 very nice analogy
dfa
+5  A: 

It's named this way because you're basically stating that the calling thread of execution is going to wait to join the given state of execution. It's also named join in posix and many other threading packages.

After that call to join returns (unless it was interrupted), the two threads of execution are basically running together from that point (with that thread getting the return value of the now-terminated thread).

Jason Coco
A: 

Because you are waiting for another thread of execution (i.e. the one you're calling join on) to join (i.e. die) to the current (i.e. the calling) thread.

The calling thread does not die: it simply waits for the other thread to do so.

+2  A: 

This stems from concurrent software modeling when the flow of control splits into to concurrent threads. Later, the two threads of execution will join again.

Also waitToDie() was probably a) too long and b) too morbid.

Aaron Digulla
A: 

This is a terminology that is widely used(outside Java as well). I take it as sort of Associating a Thread with another one in some way. I think Thread.Associate() could have been a better option but Join() isn't bad either.

Aamir
To me, Thread.associate() would imply some kind of connection between the two threads beyond the call, but as separate entities. I think that's misleading as the given thread is no longer running, but rather combining into a single execution path as defined by the call to join().
Jason Coco
+1  A: 

well... this isnt really correct but I thought of an "waiting room" (it actually isnt a queue with a certain scheduling as FIFO, HRRN or such). when a thread cannot go on and needs to wait on some other thread to finish it just joins the guys (aka threads) in the waiting room to get active next...