It's not a secret anymore!*
The moose likes Threads and Synchronization and the fly likes Synchronized Block Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Synchronized Block" Watch "Synchronized Block" New topic
Author

Synchronized Block

Dharmin Desai
Ranch Hand

Joined: Feb 28, 2002
Posts: 81
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 ]

SCJP2 (93%),SCWCD(88%)<br />-------------------------------<br />Never under estimate yr self, just represent yr profile in proper manner.
Ajith Kallambella
Sheriff

Joined: Mar 17, 2000
Posts: 5782
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.


Open Group Certified Distinguished IT Architect. Open Group Certified Master IT Architect. Sun Certified Architect (SCEA).
Dharmin Desai
Ranch Hand

Joined: Feb 28, 2002
Posts: 81
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
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4447
    
    5

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 ]

Junilu - [How to Ask Questions] [How to Answer Questions]
Mr. C Lamont Gilbert
Ranch Hand

Joined: Oct 05, 2001
Posts: 1170

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

Joined: Feb 28, 2002
Posts: 81
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

Joined: Oct 05, 2001
Posts: 1170

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.
 
subject: Synchronized Block
 
Similar Threads
Deadlock
Thread's Locks
sychronized block in synchronized method
nested synchronized statements
Deadlock?