Synchronized threads and locking
Asked Answered
F

3

8

Can someone please explain the difference between these two examples in the context of object locking:

public void method1(){
    synchronized(this){
        ....
    }
}

And

StringBuffer aStringBufferObject = new StringBuffer("A");

public void method2(){
    synchronized(aStringBufferObject){
        ....
    }
}

I know the first example will obtain a lock on the this instance and the second will obtain a lock of the aStringBufferObject instance. But i dont really understand what the effect or the difference of the two is.

For example, in the second example, will threads still be able to execute the code inside the synchronized block because the lock is not related to the 'this' instance?

I know that synchronizing a method or a block of code prevents multiple threads to access that block/method at the same time but what is the purpose of specifying the object to lock on and what is the difference in the way the object is specified as in the above examples?

Foxy answered 24/7, 2011 at 14:17 Comment(7)
See also Synchronized methods and thread locking.Joellejoellen
Also have a look here: Java Concurrency / Multithreading - TutorialPiscatory
@Andrew: ah, I though you were referring to an article, but see now that it is a multi-post.Piscatory
@HFOE "..it is a multi-post." Indeed. I was chastised for mentioning that on another question long ago (mostly for entering it as an answer - then refusing to delete the answer), so now take the more 'subtle' approach. ;)Joellejoellen
Basically, we don't have enough information (enough code) to tell you why the programmer decided differently in the two cases. It can get confusing when using synchronized(this) because it also synchronizes with synchronized methods and you might get deadlocks. You might get deadlocks too if someone uses the object as a lock somewhere else in the code. I remember reading a comment by one the Java creator saying that they should not have allowed locking on objects, but only the use of dedicated locks (i.e. java.util.concurrent.locks).Flinch
@Andrew: please use hover rather than HFOE to direct a comment to me since @ HFOE doesn't direct the comment to my inbox. For more on this, please check out: meta: how-do-comment-replies-workPiscatory
@hover Thanks for the tip & link - that clarifies a few things for me.Joellejoellen
W
8

What is the purpose of specifying the object to lock on?

Often, it is easier to synchronize on this or on the Class instance (for static methods). But, there are cases where you will need to synchronize on a specific object instead of the implicit lock (this). Such cases include:

  • You want to synchronize access to primitives without using this. You can only synchronize on Objects as each Object is associated with an implicit monitor in Java. Primitives do not have such implicit monitors, and therefore you need to use a lock object. Using the wrapper classes are a poor and incorrect choice, especially if you end up modifying the lock object in the guarded block.
  • You want to synchronize on an object that actually protects the critical section, when synchronizing on this would not offer a guarantee of thread safety. For instance, if you are synchronizing access to a ArrayList instance shared across instances of class A, then synchronizing on an instance of A is useless. A thread might create a new instance of A and gain access to the list, while another thread is modifying it. If you use a different lock that all threads must contend for then you can protect the list; this lock could be the one associated with A.class, but it could be any object that will offer the same guarantees.
  • You want to perform lock splitting to ensure that different guarded blocks are protected by different locks instead of the same lock. In other words, if it is thread-safe to allow different threads to acquire different locks to access different critical sections, then you can have a different lock for every critical section.

The following is an example of split lock usage:

private Object method1Lock = new Object();
private Object method2Lock = new Object();

public void method1(){
    synchronized(method1Lock){
        ....
    }
}

public void method2(){
    synchronized(method2Lock){
        ....
    }
}

You would use split locks when you can ensure that the concurrent execution of method1 and method2 do not violate the class invariants. This way, you can improve performance across threads that need access to the same object, but will be invoking different methods.


On your other question,

For example, in the second example, will threads still be able to execute the code inside the synchronized block because the lock is not related to the 'this' instance?

In the second example, any thread entering the guarded region must acquire the lock associated with aStringBufferObject. If a different thread is holding that lock, then the current thread will not proceed further. When you specify this, then the thread must acquire the lock associated with the current object. In both cases, a thread must acquire a lock; the examples are only different in the object that is being used as a lock.

Waler answered 24/7, 2011 at 14:41 Comment(0)
A
2

Synchronizing on an object means that other blocks which synchronize on the same object will have to wait. For example:

public void methodA() {
   synchronized(obj) {
      //Do one job
   }
}

public void methodB() {
   synchronized(obj) {
      //Do another job
   }
}

If you call methodA() in one thread and then call methodB() in another thread, methodB() won't finish before methodA() finishes.

Aquarius answered 24/7, 2011 at 14:24 Comment(0)
M
2

The synchronized block is a monitor, which leave out of details to lock and unlock a mutex. Because every object in Java has an internal lock(refer to source code of Object class), when use synchronized statement, the JVM will help you synchronize the critical section. You can also synchronize block yourself use ReentrantLock in package java.util.concurrent.locks.

Mongoose answered 24/7, 2011 at 14:40 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.