Forums Register Login

Synchronized method Behavior

+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
 

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.
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
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 ?
What do you have in that there bucket? It wouldn't be a tiny ad by any chance ...
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com


reply
reply
This thread has been viewed 916 times.
Similar Threads
Synchronized
Doubt on wait method in Threads
Practice question on synchronized
Synchronized method/blocks.....???????
Thread exit question
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 28, 2024 14:11:47.