Use of 'synchronized'

Question

Hello,
Is there any difference (other than having to declare a lock object in the second case) between :
public void synchronized myMethod(){
doSomething();
and
public void myMethod() {
synchronized(lock) {
doSomething();
Thank you.
Benoit

Answer 1

it is not only a difference in performance, but one
version is threadsafe on multiprocessor machines and
the other is not.
[snip]
The reasoning is that the synchronized keyword on a
method is handled by the jvm as a special case and has
the capability to do the locking between processors(if
it's a good jvm). The synchronized block as was
stated produces byte code (2 of them). Because of
this, the jvm can't do this additional optimization
because it cannot possibly lock both processes without
the chance of deadlock since each process can be
trying to lock each other after the first byte code,
but before it finishes the second. So therefore the
jvm must purposely not synchronize the multiple
processes.Interesting argument, but it doesn't seem to sit right.
Taken directly from the JVMS, the two instructions will roughly be...   2  aload_2      // Push local variable 2 (f)
   3  monitorenter // Enter the monitor associated with fhttp://java.sun.com/docs/books/vmspec/2nd-edition/html/Compiling.doc.html#6530
There is no possibility of deadlock by interleaving any combination of the above two bytecodes, since the monitorenter is defined as a cpu-atomic operation. From the JLS (emphasis added)...
http://java.sun.com/docs/books/jls/second_edition/html/memory.doc.html#28287
For the purposes of this chapter, the verbs use, assign, load, store, lock, and unlock name actions that a thread can perform. The verbs read, write, lock, and unlock name actions that the main memory subsystem can perform. Each of these actions is atomic (indivisible).
I read this as saying that the monitorenter instructions can be assumed to execute serially, since they are atomic operations on the shared memory. Therefore, the second CPU to execute the monitorenter instruction will find the monitor taken, and will wait for it to be released.
This of course assumes that the two processors share a single memory... else this breaks down to a distributed JVM problem, which will need extra semantics to conform to the JLS and JVMS.
If you have any links to information on the thread-safe behaviour of java on multi-processor systems, they would be greatly appreciated - the specification means to me that both constructs should be thread-safe, but if there is anecdotal evidence to the contrary...
Regards,
-Troy
PS- There were no reported bugs to this effect that I found in Sun's java bug database