• Post Reply Bookmark Topic Watch Topic
  • New Topic

Synchronized method Behavior  RSS feed

 
Cassidy Yeung
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 104
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1170
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 104
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ?
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!