• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Devaka Cooray
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Knute Snortum
  • Bear Bibeault
Saloon Keepers:
  • Ron McLeod
  • Tim Moores
  • Stephan van Hulst
  • Piet Souris
  • Ganesh Patekar
Bartenders:
  • Frits Walraven
  • Carey Brown
  • Tim Holloway

does invocation of join release the locks on objects the current holds?

 
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

According to Kathy Sierra and Bert Bates "Thread doesn't give up the lock on invocation of join "
But here main thread first acquires a lock on object 'a' and then invokes a.join which pushes the out of the running state.
The main thread cannot be scheduled until the Thread A completes. This causes the other thread to start executing so it's run method begins
and this thread tries to acquire the lock on object 'a' and successfully gets it (which is evident by the output). This can happen only if the call to a.join in main thread released the lock on object 'a' which is contrary to what the author says.
can someone please expalin whether my interpretation is correct?
thank u
Saravanakumar R
Edited By Corey McGlone: Added CODE Tags
[ July 11, 2003: Message edited by: Corey McGlone ]
 
Ranch Hand
Posts: 443
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually, if you use a different object to lock on, say a String, you would see that the join() method will not release the lock, and the program will wait forever.
But I am curious as to why if you lock the thread object itself, it appears that the join() method is releasing the lock.
Answers anyone?
 
Ranch Hand
Posts: 1090
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Please disregard this post and see the next to next post
Hi Saravanakumar
Try placing a few line in the code at these two locations

output :
main acquired a lock on a
Thread-1 acquired a lock on a
a in run Thread[Thread-1,5,main]
a in main Thread[Thread-1,5,]
true
Secondly try obtaining a lock on a String object and you will see that it may(and generally does) causes the main thread to wait for thread a.
Try this code :

[ July 11, 2003: Message edited by: Anupam Sinha ]
 
Ranch Hand
Posts: 3271
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm afraid I haven't yet found the answer, Saravanakumar.
However, I did find this little interesting tidbit. As you've seen from the previous examples, if you synchronize on some other object (in those examples, it was a String), everything works fine. However, if you synchronize on the thread itself, it breaks.
So, I tried this:

In this case, I commented out the join command and you can see that the synchronization seems to work properly. There's something funny going on with that join, but I haven't yet put my finger on it....
 
Anupam Sinha
Ranch Hand
Posts: 1090
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all
I guess that the reason to this is that join() method does releases the lock/s obtained on the thread(if any) as it can be seen from the code below that join() method internally uses the call to the wait() method. So in case you use a.join() and also synchronize on a then you lose the lock. But in case you use a.join() and synchronize on aa( any string) then you have the lock on aa and the thread goes to wait.

[ July 11, 2003: Message edited by: Anupam Sinha ]
 
Alton Hernandez
Ranch Hand
Posts: 443
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Anupam Sinha:
...join() method internally uses the call to the wait() method.




According to Kathy Sierra and Bert Bates "Thread doesn't give up the lock on invocation of join "


So is this statement incorrect then?
 
Anupam Sinha
Ranch Hand
Posts: 1090
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Alton

According to Kathy Sierra and Bert Bates "Thread doesn't give up the lock on invocation of join "


Well this statement sounds ambiguous. Which thread does "Thread" here means. But yes looking at the statement does gives me a feeling that this statement is wrong. But I might just have missed a point.
[ July 11, 2003: Message edited by: Anupam Sinha ]
 
Saravanakumar Rajmohan
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Anupam,
Thank u for the insight
 
Ranch Hand
Posts: 1392
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

This can happen only if the call to a.join in main thread released the lock on object 'a' which is contrary to what the author says.


Yes, you are correct.
The main thread creates a new thread object, Thread-1, and starts the thread.
The main thread acquires the lock of the Thread-1 object.
The main thread invokes join on the Thread-1 object.
The source code for Thread.join is basically

with the understanding that the runtime system will invoke notifyAll when the thread actually terminates.
Since the join method is synchronized, when the main thread invokes join() on the Thread-1 object,
the main thread would acquire the lock of the Thread-1 object, but it already has the lock!
The main thread invokes wait(0) on "this", the Thread-1 object (at line 6),
the main thread is added to the wait set of the Thread-1 object,
and the main thread releases the lock of the Thread-1 object.
[ July 11, 2003: Message edited by: Marlene Miller ]
 
Marlene Miller
Ranch Hand
Posts: 1392
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In a capsule, when one thread invokes join() on another thread object, the first thread acquires the lock of the thread object (because join is synchronized), invokes wait() on the thread object and releases the lock of the thread object.
In this most unusual example, the calling thread already owns the lock of the thread object for other purposes and to everyone's surprise, releases it as a normal part of executing wait() on that object.
[ July 11, 2003: Message edited by: Marlene Miller ]
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!