• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Synchronized Block

 
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The example has been given at JLS - point 14.18.

prints:
made it!
This example would deadlock if a single thread were not permitted to lock a lock more than once.
Can anybody justify "Why we need to lock object t two times here ?"
And the further JLS has told that if u don't do like that u will face "Dead Lock (Race condition)"
Please answer
Dharmin Desai
(edited to add 'CODE' blocks for readibility's sake - George)
[ June 13, 2002: Message edited by: George Brown ]
 
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Java Language Specification says under 17.5 Rules about Locks


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


Although I cannot think of a situation where you would need the lock more than once, it is perfectly legal. For instance, if you have two synchronized methods A and B and if A calls B before returing the control, the sequence will make the thread acquire two locks on the same object. Although IMO this is a very bad design.

The concept of deadlock and race condition is slightly different. So far we have been talking about a single thread scenario. Deadlocks and/or race conditions happen when more than one thread is in the playground, each thread contending for the lock. As for your example is concerned, it is quite harmless because by the time the inner synchronized block is executed, the thread already has obtained the lock on the object.
Hope that helps.
 
Dharmin Desai
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Ajith,
This will surely helpfull to me !
But the thing was "The code given was synchronized block not for method"
Please tell me "once u lock an object at synchronized block why we need to lock it again in the same synchronized block ?"
Thanks
Dhamrin
 
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Remember that the lock is on the object, not on a method. If a thread is executing a sychronized method that calls another synchronized method that requires a lock on the same object, it won't get blocked.
That is, given Thread t and Object o with synchronized methods foo() and bar(), where foo() calls bar():
Thread t:
1. call made to foo() - requires lock on o
2. Block until lock on o acquired.
3. execute foo()
4. call made to bar() - requires lock on o
5. Block until lock on o acquired.
6. execute bar()
If t wasn't aware of the fact that when it calls bar() at 4 it already had the lock on o, then it would stay blocked at 5. It's like thread t would be naively saying something like "Oops, somebody already has a lock on o... gotta wait until he gives it up before I can do bar()." forgetting that it already has the lock.
It would be also possible to recursively invoke a synchronized method. Same reasoning as above applies.
HTH,
Junilu
[ June 11, 2002: Message edited by: Junilu Lacar ]
 
Ranch Hand
Posts: 1170
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Simply put you don't need to. But doing so can significantly reduce the complexity of your program.
Also take a gander at this class

without the ability of the same Thread to lock an object more than once, this program would deadlock.
[ June 11, 2002: Message edited by: CL Gilbert ]
[ June 11, 2002: Message edited by: CL Gilbert ]
 
Dharmin Desai
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks gilbert and junilu
But one more thing ,
When we r calling another synchronized method from one synchronized method or when one synchronized method may be called recursively.
All these places need to lock a same object multiple times but i m not able to uderstand why we need to lock a same object within same synchronized block !

Thanks,
Dharmin
(added 'CODE' blocks for readability's sake - George)
[ June 13, 2002: Message edited by: George Brown ]
 
Mr. C Lamont Gilbert
Ranch Hand
Posts: 1170
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The example I gave is plausable. The example you gave is not. You are correct in questioning why anyone would create 2 interlaid synchronized blocks on the same object. It does not make any sense because the object is already locked and a good compiler could simply optimize that whole inner synchronized block away.
I think the example you gave was just an example to show that it is legal. But their is no reason every to do such a thing. Its just as meaningless as
private int x=6;
x=6;
redundant.
[ June 12, 2002: Message edited by: CL Gilbert ]
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic