• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Synchronised methods

 
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Can a synchornised method have another synchronized method. I am really confused about it.
Can somebody help.
thanks in advance
shalini
 
Ranch Hand
Posts: 1070
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If you are asking if a synchronized method can CALL another synchronized method then the answer is yes. You will get multiple locks if it is the same object, or you will get a lock on another object if you are calling the new method with a different object.
 
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Important Note: this is wrong... see my post below.
Wait -- I thought each object had only one lock -- if you call another synchronized method within the same object, I think the VM realizes the current thread already has that lock, and does nothing. Not that it really matters, as far as behavior is concerned...
-Rob
<BLOCKQUOTE>Originally posted by bill bozeman:
If you are asking if a synchronized method can CALL another synchronized method then the answer is yes. You will get multiple locks if it is the same object, or you will get a lock on another object if you are calling the new method with a different object.</BLOCKQUOTE>
[This message has been edited by Rob Whelan (edited November 03, 2000).]
 
Enthuware Software Support
Posts: 4810
52
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This post may help you... http://www.javaranch.com/ubb/Forum24/HTML/005130.html
Also, I would like to make a little correction to Aru Ven's post there. If a thread re-accuires the same lock, it still owns only one lock and not 2. No matter how may times a thread accuires the same lock, it still owns only one (that) lock. Of course, a thread can accuire locks for different objects. In that case, it may own multiple locks.
-Paul.

------------------
Get Certified, Guaranteed!
(Now Revised for the new Pattern)
www.enthuware.com/jqplus
 
Rob Whelan
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Paul Anil:
Also, I would like to make a little correction to Aru Ven's post there. If a thread re-accuires the same lock, it still owns only one lock and not 2.


Actually, Aru is correct (and my post above is also wrong). Interestingly, I'm quite sure I've read that a Thread will only acquire one lock on a given object (as Paul and I described above), but in fact that is incorrect.
The JLS says clearly that "a thread may acquire the same lock multiple times and doesn't relinquish ownership of it until a matching number of unlock actions have been performed".
Oops. I'll put a note in my post above as well...
Here's the section from the language spec in full:
17.5 Rules about Locks
Let T be a thread and L be a lock. There are certain constraints on the actions performed by T with respect to L:
A lock action by T on L may occur only if, for every thread S other than T, the number of preceding unlock actions by S on L equals the number of preceding lock actions by S on L. (Less formally: only one thread at a time is permitted to lay claim to a lock, and moreover a thread may acquire the same lock multiple times and doesn't relinquish ownership of it until a matching number of unlock actions have been performed.)
An unlock action by thread T on lock L may occur only if the number of preceding unlock actions by T on L is strictly less than the number of preceding lock actions by T on L. (Less formally: a thread is not permitted to unlock a lock it doesn't own.)
With respect to a lock, the lock and unlock actions performed by all the threads are performed in some total sequential order. This total order must be consistent with the total order on the actions of each thread.
 
Paul Anilprem
Enthuware Software Support
Posts: 4810
52
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Oops...glad that you pointed it out, Rob. (I think I got to make a revision of JLS again!)
-Paul.
------------------
Get Certified, Guaranteed!
(Now Revised for the new Pattern)
www.enthuware.com/jqplus
 
Ranch Hand
Posts: 3141
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi guys ... just adding my 2-cents
Java uses re-entrant threads which means a thread cannot lock on itself.
The following is from the Sun Tutorial on threads:

In the above code, the synchronized method a(), when executed, obtains a lock on it's own object.
It then calls synchronized method b() which also needs to acquire a lock on it's own object
If Java did not allow a thread to reacquire it's own lock method b() would be unable to proceed until method a() completed and released the lock; and method a() would be unable to complete until method b() completed. Result: deadlock

As Java does allow reentrant locks, the code compiles and runs without a problem
------------------
Jane
The cure for boredom is curiosity.
There is no cure for curiousity.
-- Dorothy Parker
[This message has been edited by Jane Griscti (edited November 03, 2000).]
 
SHALINI PATEL
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks JANE, that was quiet clear..
I hope I get through the threads topic......... Its very strange for me
Thanks everybody.........
reply
    Bookmark Topic Watch Topic
  • New Topic