• Post Reply Bookmark Topic Watch Topic
  • New Topic

synchronized question  RSS feed

 
Jerry Chen
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
Does anyone know if the following code causes deadlock?
Object monitor, A, B;
public void method()
{
synchronized(monitor)
{
synchronized(A)
{
... // some code
}
synchronized(B)
{
... // some code
}
synchronized(B)
{
... // some code
}
synchronized(A)
{
... // some code
}
}
}
 
Ellen Zhao
Ranch Hand
Posts: 581
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
4 conditions for deadlock: ( Coffman 1971 )
  • Resources are exclusive available
  • Process has already hold a resource, but still acquiring other resources
  • No force of release on resources
  • There exists a process cycle ( classic example: Dining Philosophers )


  • your code hits the second condition( the nested sychronisation ), there would be a deadlock.
    Regards,
    Ellen
     
    Jerry Chen
    Greenhorn
    Posts: 2
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi Ellen,
    Are you saying any form of nested synchronized code will cause deadlock? If I take out the inner synchronized keywords on object A and B, can I assume the code will be thread safe? Thanks
    Jerry
     
    Joe Cheng
    Greenhorn
    Posts: 11
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Ellen, are you sure this code will deadlock? Assuming this is the only method that synchronizes on monitor, A, and B, I don't think it will deadlock.
    This is the kind of nested synchronization that will definitely deadlock:
    method 1:
    lock A
    lock B
    method 2:
    lock B
    lock A
    Only where the order of nested lock acquisition is different do you have the potential for deadlock (which is very easy to do if you're not careful). If you always acquire nested locks in the same order you're safe.
     
    Ellen Zhao
    Ranch Hand
    Posts: 581
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    I never said nested synchronisations would necessarily cause deadlock. Sorry for my vague interpretion of this: Process has already hold a resource, but still acquiring other resources
    Okay, assume, there was a thread A, which holds the lock on the Object A; And a moment later, there was another thread, say, thread C entered the Synchronized(monitor) block, then thread C would acquire the lock on Object A. But the lock on Object A was still hold by thread A, if thread A never terminated, the poor thread C has no chance. If thread C was the very crucial thread in the whole process( say, the main thread is waiting for thread C ). Deadlock.
    If there is any mistake in my words, please point out. Thanks.

    Regards,
    Ellen
     
    Ellen Zhao
    Ranch Hand
    Posts: 581
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Oh, sorry, I just misread your code, I took the first synchronized (A) was nested in the synchronized (monitor) block, but all the rest were not nested. hmmm, so, what Joe said makes sense. But there is still possibility that deadlock would occur. And more possibility for reentrant. Depends on how you implement the "//some code".
    If Jerry you could offer more information of the environment of your code( say, what the "//some code" are ), that would make the deadlock analysis more certain.

    Regards,
    Ellen
    PS.: It would be very kind of you if you could apply the code tag in your post, that would make your code much more readable. Thank you very much!
    [ February 25, 2003: Message edited by: Ellen Zhao ]
     
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!