Question related to Thread synchronization.

[Hrishikesh Yeshwant Alshi]

Question IV: (Question form Enthuware)

public class TestClass extends Thread
{
   static Object lock1 = new Object();
   static Object lock2 = new Object();
   static volatile int i1, i2, j1, j2, k1, k2;
   public void run()
   {
      while (true)
      {
         workWithLocks();
         workWithoutLocks();
      }
   }
   void workWithLocks()
   {
      synchronized(lock1) { i1++ ;  i2++; }
      synchronized(lock2) { k1++ ; k2++ ; }
      j1++;    j2++;
   }
   void workWithoutLocks()
   {
      if (i1 != i2) System.out.println("i");
      if (j1 != j2) System.out.println("j");
      if (k1 != k2) System.out.println("k");
   }
   public static void main(String args[])
   {
      new TestClass().start();
      new TestClass().start();
   }
}

The explanation given in the enthuware is either incorrect or I failed to understand it. It says …

For each invocation of workWithLocks(), each variable pair is incremented and their values are always equal when the method returns.
The only way a letter could be printed would be if the method workWithoutLocks() was executed between the time the first and the second variable was incremented.
Since the workWithoutLocks() method does not depend on owning any monitor, it can be executed at any time, and the method workWithLocks() cannot protect the atomic nature of its operations by acquiring monitors.
The moral of the story is : It does not matter if a methods does it's job by acquiring monitors or not. What matters is whether ALL the methods that use shared resources do their job after acquiring monitors or not. Because, acquiring a monitor will not prevent any other method which does not use monitors, from accessing the shared resource.


MY DOUBT:

Please observe that the method ‘workWithLocks()’ is actually acquiring the lock on the objects (lock1) and (lock2) and not on ‘this’. What is the use of these locks? How would it prevent the variables i1, i2, j1, j2, k1, k2 from concurrent access i.e liveness failure and safety failure? It is as good as the method ‘workWithLocks()’ is not working with locks.

[Mohamed Sanaulla]

The Locks are used to avoid Race conditions when multiple threads are trying to access the shared resource- These in no way to prevent the other method to access the shared resource if its not synchronized.

You can try removing the synchronized blocks from the workWithLocks method and see- each time you execute- the values of i1 and i2 will be different. With the synchronized block- we can ensure that i1 and i2 are incremented together.

The explanation given is correct.

[Hrishikesh Yeshwant Alshi]

I am sorry, but may I get your attention to the below point?

Observe that the method ‘workWithLocks()’ is actually acquiring the lock on the objects (lock1) and (lock2) and NOT on ‘this’.

The variables i1, i2, j1, j2, k1, k2 are NOT the members of Object lock1 or Object lock2.

Acquiring the lock on Object lock1 or Object lock2 CANNOT prevent threads from accessing variables i1, i2, j1, j2, k1, k2 concurrently.

Further, declaring variables i1, i2, j1, j2, k1, k2 would NOT help either as volatile will ONLY make sure that all the threads will always receive the latest value of these variables.

Am I right?

[Mohamed Sanaulla]

The moral of the story is : It does not matter if a methods does it's job by acquiring monitors or not. What matters is whether ALL the methods that use shared resources do their job after acquiring monitors or not. Because, acquiring a monitor will not prevent any other method which does not use monitors, from accessing the shared resource.

The above explains everything.

Hrishikesh Yeshwant Alshi wrote:The variables i1, i2, j1, j2, k1, k2 are NOT the members of Object lock1 or Object lock2.

Its not necessary for the shared resource to be part of the object on which they are locking. The whole point of using locks is that- You allow one thread to execute in that block and there by protecting your shared resource. So if you have other methods or other block of code accessing the shared resource- You need to synchronize that block.

[Hrishikesh Yeshwant Alshi]

Thanks much Mohamed .

Its not necessary for the shared resource to be part of the object on which they are locking. The whole point of using locks is that- You allow one thread to execute in that block and there by protecting your shared resource. So if you have other methods or other block of code accessing the shared resource- You need to synchronize that block.

I was under the impression that "It IS NECESSARY for the shared resource to be part of the object on which they are locking." I don't know from where I picked it up. May be it was my own WRONG understanding.

I am happy that the misconception is wiped off.

Thanks much.