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.
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).
Joined: Feb 28, 2002
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
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 ]
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 ]
Joined: Feb 28, 2002
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 ]
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 ]