aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes problem understanding Thread.join() Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "problem understanding Thread.join()" Watch "problem understanding Thread.join()" New topic
Author

problem understanding Thread.join()

Sigrid Kajdan
Ranch Hand

Joined: Jan 14, 2007
Posts: 72
Hello,

I have problems understanding the join() method of Thread. If I get it right, when I have two threads A and B, and thread A calls b.join(), thread A will be waiting for B to finish.
But looking at the Thread class, I see that join() calls wait, so I'd suppose that when A calls b.join() it ought to be B who has to wait...

It's clear that I'm wrong there, but I can't imagine where it's wrong...

Can anyone give me a hint? Thanks!
Vlado Zajac
Ranch Hand

Joined: Aug 03, 2004
Posts: 245
wait() always pauses current thread (which is A) not the thread on which it is called (if it is called on Thread instance - it can be called on any object).
Sigrid Kajdan
Ranch Hand

Joined: Jan 14, 2007
Posts: 72
Thank you very much for your answer. I'm sorry, but somehow I don't really get it yet... I'd suppose that when I call b.join(), it should be b who calls wait(), like when I have an instance of, say, a Logger object and I call

logger. info()

and it's the logger who calls his info() method...

Sorry for not getting it...
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18896
    
  40

Originally posted by Sigrid Kajdan:
Thank you very much for your answer. I'm sorry, but somehow I don't really get it yet... I'd suppose that when I call b.join(), it should be b who calls wait(), like when I have an instance of, say, a Logger object and I call

logger. info()

and it's the logger who calls his info() method...

Sorry for not getting it...


It may not be intuitive to you, but that is how it works. When you call b.wait(), it is the current thread (the caller) that waits. Now, the reason the method is not static, is because it also releases and reacquires a lock during this process. This lock is the lock of the thread b object.

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Sigrid Kajdan
Ranch Hand

Joined: Jan 14, 2007
Posts: 72
Thanks for the reply. I will certainly have to study the thread topic further.
For example, the locking topic...

Now, the reason the method is not static, is because it also releases and reacquires a lock during this process. This lock is the lock of the thread b object.


I suppose it's a silly question, but when join() calls wait(), I wonder where it is communicated which object's lock is released/reacquired?
I see thread b involved in b.join(), but then I only see a call to wait without a lock object mentioned...

Anyway, I suppose I still lack real understanding of threading, so if my current question is too absurd please don't bother answering it. Anyway, I want to read a book on threads as soon as I'll have time...
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18896
    
  40

I suppose it's a silly question, but when join() calls wait(), I wonder where it is communicated which object's lock is released/reacquired?
I see thread b involved in b.join(), but then I only see a call to wait without a lock object mentioned...


The join() method calling the wait() method is merely an implementation detail. In the future, it may be implemented differently. However, the current implementation, calls the wait() method of the Thread object -- which in your example is the "b" object.

As for the wait() method releasing and acquiring locks, that is described in the JavaDoc for the wait() method (located in the Object class).

Henry
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: problem understanding Thread.join()