synchronized keyword

When you say...

What would that be saying in "english"? Is it basically a sleep call on a thread until a different thread is finished in this block of code?

Hmmmm. English. I'm at a loss for a decent english version, unless you want it to be four paragraphs long. But I'll it the short version a shot...:
"Now class, let me introduce you to our new talking stick, Mr. 'object.' If you wish to speak, wait quietly until whoever is using the talking stick currently finishes. Grabbing of the talking stick from another student's hands is strictly prohibited. If nobody is holding the talking stick, you may simply pick it up."
This is an extremely poor analogy, but it's the best I can think of at the moment.

That sounds like what I said above, is that correct?

"sleep call" is really insufficient to describe what actually happens.
For example, any thread local memory caches (just some silly JVM optimizations) are brought up to date when you enter a synchronized block.
And it's not about "this block of code". The lock is tied to the object you're locking on (or the object's "monitor" in JLS speak...). I can have synchronized blocks spread all throughout my application that synchronize on the same object in completely different contexts.
The lock is also re-entrant. If methodThatAquiresALock() calls anotherMethodThatAquiresALockOnTheSameObject(), or for that matter if it simply calls itself recursively, the same lock is kept instead of the program blocking infinately. That may seem self-evident, but it's not the only option for lock semantics.
There's also the Object.wait() method that temporarily gives up a lock yet remains within a synchronized block.
But despite all the subtleties of synchronization in Java, the "sleep call" interpretation may be perfectly sufficient for your purposes.
[ June 22, 2003: Message edited by: David Weitzman ]

Also, a sleep() call would be interruptible, or could be set to time out after a certain period. Neither of these is an option if your thread is trying to acquire a lock on a monitor (at the beginning of a synch block). Which means that if you manage to create a deadlock situation, there may be no way to recover from it (other than revising the code so it doesn't happen again). So sleep() is different from acquiring a lock. Note that it's also common to refer to the latter as "waiting" for a lock - but this is dangerously misleading, because wait() is yet another method with different behavior from either sleep() or lock aquisition.

Originally posted by David Weitzman:
Hmmmm. English. I'm at a loss for a decent english version, unless you want it to be four paragraphs long. But I'll it the short version a shot...:
"Now class, let me introduce you to our new talking stick, Mr. 'object.' If you wish to speak, wait quietly until whoever is using the talking stick currently finishes. Grabbing of the talking stick from another student's hands is strictly prohibited. If nobody is holding the talking stick, you may simply pick it up."
This is an extremely poor analogy, but it's the best I can think of at the moment.

great!