Clarification of synchronized blocks

Hi folks,
The syntax of the synchronized statement is:
��synchronized (object-expression)
��{ // critical section
��statement
��}
The object-expression must evaluate to an object.
Can anyone develop this a little further. Does the argument represent the object that has obtained the monitor to this mutually exclusive piece of code?
If so, does this mean that only objects of a certain type can access the block, while others have to 'ignore' it and carry on?
Regards,
merlin_bar

Originally posted by merlin bar:
Hi folks,
The syntax of the synchronized statement is:
synchronized (object-expression)
{ // critical section
statement
}
The object-expression must evaluate to an object.
Can anyone develop this a little further. Does the argument represent the object that has obtained the monitor to this mutually exclusive piece of code?
If so, does this mean that only objects of a certain type can access the block, while others have to 'ignore' it and carry on?
Regards,
merlin_bar

Hi Merlin,
Think of the object-expression as the treadmill down at your local gym. When you synchronize on it, what you(the gym owner) are saying is this:
"anyone who wants to use the treadmill(object-expression) must sign it out to use it, and everyone else agrees not to try to use it while it's currently being used".
So who are these 'anyone' and 'everyone else' people in this analogy? They are other threads, of course.
Thus, when a given thread(say John) reaches 'object-expression', that thread(John) is promised exclusive use of that 'object-expression'(the treadmill), until that thread(Again, John) reach the end of the synchronized block. They John releases the resource(treadmill), and the other people(other threads) who we waiting for it get to call dibs.
It�s important to note that these other people(threads) don�t necessarily get any sort of a priority because they were �first in line�. That�s operating system specific behavior. To put it another way, some gyms might give a person(again, a thread in this analogy) preference based on the amount of time they�ve been waiting, or the priority of their membership, or some balance of the two.
At this point, you should have a lot of questions: like, where does notifyAll fit into all of this? What happens if a synchronized block calls another synchronized block(say even one synchronized on a different object-reference)? How do synchronized methods fit into this whole picture?
But then again, you might not.

M, author
The Sun Certified Java Developer Exam with J2SE 1.4
All best,

Thanks Max,
that was a good explanation (I just joined a gym last week

).
I was trying to understand this code segment, which exists in a method that is called by the main app (not a thread).
I can understand what effect the code HAS on the first player (player[o]), but not why it needs to be synchronized.

Again, I believe I understand your explanation, but what is the significance of synchronizing this code? I would expect the same effect without (although without synchronization, the game cannot start).
Regards,
merlin_bar

Merlin,
I'm going to reproduce the code below, and add line numbers.

If the code were not synchronized, then another thread could sweep in between lines 1 and 2, or even while line 2 or 3 were in the middle of executing, and corrupt the state of players[0]. For example, the following code could execute

Again with the analogies: think of it this way. A given referee is talking to player[0], and he wants a guarantee the another referee won't step in and interrupt him while he's unsuspending player[0].
Make sense?
M, author
The Sun Certified Java Developer Exam with J2SE 1.4
[ February 23, 2003: Message edited by: Max Habibi ]