0

I'm having some trouble wrapping my head around the concept of synchronized blocks in Java. I feel I have understood synchronized methods well enough. So I thought of an analogy to help me understand synchronized blocks in terms of synchronized methods. Please let me know if this equivalence that I have proposed is correct. Also, I have only mentioned this for a non-static synchronized block for now. However, points on static synchronzied blocks are also welcome.

public void method() 
{
    //code snipppet A

synchronized(objRef) 
{ 
    //code snipppet B
}
    //code snipppet C
}

Is equivalent to

public void method() {
//code snippet A
objRef.sync_method();
//code snippet C
}

In the class of objRef:

public synchronized void sync_method() {
//code snippet B
}

This analogy is based on the logic that synchronized blocks behave just as synchronized methods do. Meaning that once a thread acquires a lock on the monitor, it does not allow other threads to interfere in its execution. The thread relinquishes control only once it has finished executing the entire synchronized method.

  • I *think* you got it. To make it clearer, `synchronized void method() { blabla(); }` is a shortcut for `void method() { synchronized(this) { blabla(); } }`. Both consist in getting the lock associated with the object `this`, then executing the code in blabla(), then releasing the lock. – JB Nizet Oct 30 '16 at 13:22
  • 1
    Just to clarify, you only lock objects not methods. When you have a synchronised method, it still locks an object, not the method. – Peter Lawrey Oct 30 '16 at 13:26

2 Answers2

2

There is a possibility that you're not getting everything right. For example,

synchronized(objRef) {
    objRef.nonsync_method();
    ... more code ...
}

is not equivalent to

objRef.sync_method();

because in the former case the lock covers a larger part of the code. Equivalence exists between

synchronized void sync_method() {
    // stuff
}

and

void nonsync_method() {
    synchronized (this) {
        // stuff
    }
}

Further,

once a thread acquires a lock on the monitor, it does not allow other threads to interfere in its execution

The above may or may not be true, depending on how we interpret the ambiguous wording. A thread that has acquired a lock may easily allow other threads to interfere with its execution: all it takes is another piece of code not covered by exactly the same lock. For example,

int i;

synchronized void sync_method() {
    i = 0;
    System.out.println(i);
}

void nonsync_method() {
    i = 42;
}

The call to sync_method() can print both 0 and 42.

Marko Topolnik
  • 195,646
  • 29
  • 319
  • 436
  • As for your first point, that is exactly what I meant in my question. You have written in it a clearer and more specific way. I will edit my question to reflect that. As for your _second_ point though, I do not understand how a call to `sync_method()` can print both 0 and 42. –  Oct 30 '16 at 16:28
  • 1. Call syncMethod. 2. i = 0; 3. Another thread calls nonsyncMethod. 4. i = 42; 5. Print i. – Marko Topolnik Oct 30 '16 at 16:38
  • Okay, I see what you mean now. –  Oct 30 '16 at 16:42
1

You should notice that there are two types of synchronized block in Java (object synchronize and class synchronize). There are two synchronized methods (static and non-static methods) and their equivalent synchronized blocks (Class and Object Synchronized blocks respectively). assume we have:

class MyClass{
public synchronized static void syncStaticMethod(){...}
public synchronized void syncNonStaticMethod(){...}
}


MyClass objRef = new MyClass();

1. Object Synchronization:

public void method() {synchronized(objRef) { ... }}

Is equivalent to

 public void method() {objRef.syncNonStaticMethod();}

2. Class Synchronization:

 public void method() {synchronized(MyClass.class) { ... }}

Is equivalent to

   public void method() {MyClass.syncStaticMethod();}
Community
  • 1
  • 1
Atefeh
  • 114
  • 5
  • For the last snippet, you mean `MyClass.syncStaticMethod();`. But there's no much point in making a distinction. MyClass.class is an object like any other object, and you can perfectly synchronize the body of an instance method on a Class object if you need to. – JB Nizet Oct 30 '16 at 13:57
  • Shouldn't the nomenclature of the two methods be opposite (considering static and non-static)? –  Oct 30 '16 at 16:44