The moose likes Threads and Synchronization and the fly likes Synchronized method Behavior Big Moose Saloon
  Search | Java FAQ | Recent Topics
Register / Login
JavaRanch » Java Forums » Java » Threads and Synchronization
Reply Bookmark "Synchronized method Behavior" Watch "Synchronized method Behavior" New topic
Author

Synchronized method Behavior

Cassidy Yeung
Greenhorn

Joined: Apr 03, 2003
Posts: 2
I have discussed this problem with people but they all seem quite confused about it. Can any one help me?
// position a
synchronized void A() { <-- method
// position b
B();
}
synchronized void B() { <-- method
// position c
C();
}
synchronized void C() { } <-- method
synchronized void D() { <-- method
C();
}
There are two threads running naming 1 and 2.
Thread 2 called method D, locked method C and did not exit. What will happen when thread 1 calls method A now?? Will it suspend before calling method A (position a), immediate after calling method A (position b) or after entering method B (position c) ??
Please help. Thanks in advance.
raimondas zemaitis
Ranch Hand

Joined: Feb 23, 2001
Posts: 104
Think that way: all methods declare synchronization on this instance level (not code block synchronized on some separate lock object) so any thread calling any of synchronized methods has to get lock for this instance first. So - any thread by accessing method synchronized this way will lock this object. No other threads can assess it while it is locked. Lock is per object instance, not per method. You can't lock single method, you can lock all code inside method by synchronizing on some external object but this means that in order to access synchronized code any thread will have to get lock of this external object and in fact will lock that external object, not method thread actually is working in.
Mr. C Lamont Gilbert
Ranch Hand

Joined: Oct 05, 2001
Posts: 1158

Originally posted by Cassidy Yeung:
What will happen when thread 1 calls method A now??

It won't be allowed in until thread 2 releases the lock.

Will it suspend before calling method A (position a), immediate after calling method A (position b) or after entering method B (position c) ??

position a. It will wait there until it can get the lock, but it won't be suspended. It will be repeatidly trying to grab the lock, and when the lock is available, it will take it, and do its thing.
Cassidy Yeung
Greenhorn

Joined: Apr 03, 2003
Posts: 2
Thank you very much.
Just want to check whether my understanding is correct. Does it mean the following??
Every time when the thread enters the method, it has to check whether all locks inside the method are available. If all locks are available, it can enter the process, otherwise it will wait outside. When it is entered into the method, it will lock all the related object instances before it really walks down to those synchronized methods.
And when I obtained the lock of the object instance and entered one of the synchronized methods, I cannot enter other synchronized methods in the same object instance.
If we have several layers of synchronized methods (i.e. synchronized methods inside synchronized methods), all object instances of the synchronized methods are locked. If there are six or seven layers, it may be hard to manage. Therefore we should prevent all these unless it is necessary.
raimondas zemaitis
Ranch Hand

Joined: Feb 23, 2001
Posts: 104
It is not by default to obtain a lock, thread has to get lock if it is about to enter synchronized method or synchronized block of code. Locks are not per method but per object. When thread enters synchronized piece of code JVM will first look if lock for this object is available (it is kind of counter, if it is 0 that means nobody is there and access to current thread is given. At the same time lock is incremented. If other thread tries to execute that piece of code it will be suspended by JVM. If thread, which currently owns lock enters another synchronized piece of code JVM just checks that lock owner is same thread and will grant access thus increasing counter by 1. When thread exits synchronized piece lock counter is decreased, until it is equal to 0. Then JVM assumes object is unlocked.
Does that help ?
 
 
subject: Synchronized method Behavior
 
Threads others viewed
Practice question on synchronized
Thread exit question
Synchronized
Doubt on wait method in Threads
Synchronized method/blocks.....???????
developer file tools

cast iron skillet 49er

more from paul wheaton's glorious empire of web junk: cast iron skillet diatomaceous earth rocket mass heater sepp holzer raised garden beds raising chickens lawn care CFL flea control missoula heat permaculture