synchronize section does not (always) block!

[David Holmes]

Eduard,

Both threads are blocked trying to acquire the lock, neither has acquired it.

David Holmes

On 13/07/2010 9:21 PM, Eduard Wirch wrote:
> Hi
>
>
> I've noticed something very strange yesterday. It seems that in app two threads are entering two synchronized blocks locking on the same object at the same time.
>
> The class (MyClass) containing the relevant code looks similar to this:
>
> ------------------------------------------------------------------
> private static int[]    myLock  = new int[0];
>
> protected static int methodA(final long handle, final byte[] sort) {
>      synchronized (myLock) {
>          return xsMethodA(handle, sort);
>      }
> }
>
> protected static int methodB(final long handle) {
>      synchronized (myLock) {
>          return xsMethodB(handle);
>      }
> }
> ------------------------------------------------------------------
>
>
>
> I created a thread dump of my application running the above class and was very surprised as I saw this:
>
> ------------------------------------------------------------------
> "http-8080-136" daemon prio=10 tid=0x00000000447df000 nid=0x70ed waiting for monitor entry [0x00007fd862aea000]
>     java.lang.Thread.State: BLOCKED (on object monitor)
>      at com.MyClass.methodA(MyClass.java:750)
>      - locked<0x00007fd8a6b8c790>  (a [I)
>      at com.SomeOtherClass.otherMethod(SomeOtherClass.java:226)
>      ...
>
> "http-8080-111" daemon prio=10 tid=0x00007fd87d1a0000 nid=0x70c8 waiting for monitor entry [0x00007fd86e15f000]
>     java.lang.Thread.State: BLOCKED (on object monitor)
>      at com.MyClass.methodB(MyClass.java:991)
>      - locked<0x00007fd8a6b8c790>  (a [I)
>      at com.SomeOtherClass.yetAnotherMethod(SomeOtherClass.java:3231)
>      ...
>
> "http-8080-146" daemon prio=10 tid=0x00007fd786dab000 nid=0x184b waiting for monitor entry [0x00007fd8393b6000]
>     java.lang.Thread.State: BLOCKED (on object monitor)
>      at com.MyClass.methodC(MyClass.java:750)
>      - waiting to lock<0x00007fd8a6b8c790>  (a [I)
>      at com.SomeOtherClass.yetAnoterMethod2(SomeOtherClass.java:226)
>      ...
> (43 more threads waiting for the lock)
> ------------------------------------------------------------------
>
> (I changed the class and method names for the case of simplicity, so don't get confused by the silly names.)
>
>
> It seems that thread http-8080-136 and http-8080-111 have both acquired the lock on myLock. It is the same object as the object address is the same: 0x00007fd8a6b8c790.
>
> The Java Runtime Specification says this about the synchronized keyword:
> ------------------------------------------------------------------
> A synchronized statement acquires a mutual-exclusion lock (§17.1) on behalf of the executing thread, executes a block, then releases the lock. While the executing thread owns the lock, no other thread may acquire the lock. [The Java Language Specification, 14.19]
> ------------------------------------------------------------------
>
> So how is this even possible?
>
>
> Regards,
> Eduard
>