aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Synchronised methods 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 "Synchronised methods" Watch "Synchronised methods" New topic
Author

Synchronised methods

SHALINI PATEL
Ranch Hand

Joined: Oct 31, 2000
Posts: 41
Can a synchornised method have another synchronized method. I am really confused about it.
Can somebody help.
thanks in advance
shalini
bill bozeman
Ranch Hand

Joined: Jun 30, 2000
Posts: 1070
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.
Rob Whelan
Ranch Hand

Joined: Oct 18, 2000
Posts: 33
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).]
Paul Anilprem
Enthuware Software Support
Ranch Hand

Joined: Sep 23, 2000
Posts: 3293
    
    7
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


Enthuware - Best Mock Exams and Questions for Oracle/Sun Java Certifications
Quality Guaranteed - Pass or Full Refund!
Rob Whelan
Ranch Hand

Joined: Oct 18, 2000
Posts: 33
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
Ranch Hand

Joined: Sep 23, 2000
Posts: 3293
    
    7
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
Jane Griscti
Ranch Hand

Joined: Aug 30, 2000
Posts: 3141
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).]


Jane Griscti
SCJP, Co-author Mike Meyers' Java 2 Certification Passport
SHALINI PATEL
Ranch Hand

Joined: Oct 31, 2000
Posts: 41
Thanks JANE, that was quiet clear..
I hope I get through the threads topic......... Its very strange for me
Thanks everybody.........
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Synchronised methods