This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
This question is about synchronized blocks, not synchronized methods. Does a synchronized block: A. Prevent multiple threads from executing any methods belonging to the object that is locked? B. Prevent multiple threads from executing the synchronized block at the same time, but allows multiple threads to call various methods on the object?
A. Nope, not the unsynchronized methods B. True & False! badly worded... The "various method" thing is not clear... If various means unsynchronized then it's true, otherwise if various means both synchronized and unsynchronized methods, then it's false...
Synchronized blocks (or methods) are executed by only one thread at a time. Multiple threads may invoke unsynchronized methods of an already locked object at will. Which makes sense, otherwise what would be synchronized methods good for ? HIH [ January 31, 2002: Message edited by: Valentin Crettaz ]
I meant "any method" instead of "various methods". So are you saying that when a thread has an lock on a object (via a synchronized block), other threads cannot execute the synchronized code block and cannot execute any synchronized methods belonging to the object. How about if the object does not have any synchronized methods, but is locked via a synchronized block? Does that mean that the threads that do not have the lock are free to call any methods on the object, but are restricted from executing the synchronized block of code?
Joined: Aug 26, 2001
That's exactly right, Bob... See that like this: There is exactly one and only one lock per instance object (for instance locking) and one lock per Class (for class locking). A synchronized block is not very different than a synchronized method, that is, the same lock is acquired. But, there are two slight differences between sync blocks and methods: - usually synchronized blocks are used in order to avoid synchronizing the whole method (not efficient if only one or two statements are critic) - a non-static synchronized method automatically locks the instance object (i.e., this) containing the method, while a static synchronized method automatically locks the class (i.e., ClassName.class). With a synchronized block you can lock any object, not only the instance or the class itself, but any object... HIH
Every object can have a lock associated with it. IF a thread obtains a lock on an object, that will cause other threads to block when they attempt to access any method or block that also tries to obtain the same lock.
If a method in a Thread A calls method1() on an instance of the above class, and Thread B tries to call the same method, OR method2(), Thread B will have to wait until Thread A is done executing method1() at which point in releases the lock. A synchronized block works the exact same way, except you explicitly decide which object to lock on. This code is equivalent to the above code:
In both examples, the object lock is obtained for the actual instance of the class who's methods are being invoked. When you use a synchronized block however, you are free to lock on a different object as needed for your particular design purpose.
In this last example, I'm locking on an object that is different from the object who's methods I am invoking. In this specific example, I am locking on the Class object for this class. The effect of this would be that no two object instances of this class would be able to execute their methods at the same time; ie, only one instance at a time would be allowed to execute these methods. Rob