• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

problem understanding Thread.join()

 
Sigrid Kajdan
Ranch Hand
Posts: 72
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 245
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 72
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Marshal
Pie
Posts: 21005
77
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Sigrid Kajdan
Ranch Hand
Posts: 72
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Marshal
Pie
Posts: 21005
77
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic