CODEWITHSUNDEEP
javamultithreadinglocking
peter
peter

Reputation: 8473

Why can't we acquire lock when it's private?

Why does making the lock object private encapsulate the lock so that client code cannot acquire it ?

Object's Intrinsic Lock

   public class A{
        private final Set<Integer> set = new HashSet<Integer>();

        public synchronized void addInt(int i){
            set.add(i);
        }
   }

Private Lock

   public class B{
        private final Set<Integer> set = new HashSet<Integer>();

        public void addInt(int i){
             synchronized(set){
                  set.add(i);
             }
        }
   }

Upvotes: 0

Views: 534

Answers (3)

Cratylus
Cratylus

Reputation: 54074

Why does making the lock object private encapsulate the lock so that client code cannot acquire it ?

To be honest I have no idea what is the meaning of this question.
The difference between your code snippets is the lock used. In the first case the whole method is synchronized (using the A's intrinsic lock) while in the second case you lock on the collection you are trying to modify. I.e. 2 threads can enter the method concurrently but 1 will block trying to get lock for the add.
This method has 2 advantages: 1) it defines the granularity of locking (for long methods where you would need the lock only for a short time, locking for the entire duration of the method call would degrade performance) and 2) by locking on the collection you make it thread safe.
Note that you could use any object as a lock: Object lock = new Object();
synchronized(lock){
//do something
}

Upvotes: 0

yshavit
yshavit

Reputation: 43391

Well, another class can't access set at all, because it's private. Of the many things everyone else can't do because they don't have access to that reference, synchronizing on it is one.

If a getter returns that reference directly (without wrapping or copying the object), someone else can synchronize on it, defeating the benefits of a lock on a private object.

Upvotes: 3

Paul Morie
Paul Morie

Reputation: 15778

In both of the examples you provided, an intrinsic monitor is used. The second example, however, uses the intrinsic lock of the set field. Take care when using this practice: if you publish a reference to set, code outside your class could synchronize on its monitor, which could lead to dead lock.

I think the distinction you're getting at is synchronized versus using the java.util.concurrent.Lock API. Most of what you get is added flexibility (from the Lock docs):

The use of synchronized methods or statements provides access to the implicit monitor lock associated with every object, but forces all lock acquisition and release to occur in a block-structured way: when multiple locks are acquired they must be released in the opposite order, and all locks must be released in the same lexical scope in which they were acquired.

While the scoping mechanism for synchronized methods and statements makes it much easier to program with monitor locks, and helps avoid many common programming errors involving locks, there are occasions where you need to work with locks in a more flexible way. For example, some algorithms for traversing concurrently accessed data structures require the use of "hand-over-hand" or "chain locking": you acquire the lock of node A, then node B, then release A and acquire C, then release B and acquire D and so on. Implementations of the Lock interface enable the use of such techniques by allowing a lock to be acquired and released in different scopes, and allowing multiple locks to be acquired and released in any order.

There are also two method calls which give you more ways to acquire a lock with the Lock API:

  • lockInterruptibly: acquire the lock unless the thread is interrupted.
  • tryLock: acquire the lock only if it is free at the time of invocation (optional timeout).

The canonical reference for concurrency in Java is 'Java Concurrency in Practice'.

Upvotes: 1

Related Questions