About Question enthuware.ocpjp.v11.2.3363 :

[hsnclk]

What if we changed the order of Data objects like below; would a livelock or deadlock occur?

Code: Select all

new Thread(() -> {w1.write(d1,d2);}).start();
new Thread(() -> {w2.write(d2,d1);}).start(); 

[admin]

what do you think?

[dameest]

What if we changed the order of Data objects like below; would a livelock or deadlock occur?

Code: Select all

new Thread(() -> {w1.write(d1,d2);}).start();
new Thread(() -> {w2.write(d2,d1);}).start(); 

There may be a deadlock in this situation. If thread 1 changes d1.writer while thread 2 changes d2.writer, both will be blocked on the second while loop.

[dameest]

Well, I had the correct response, but the while loop is so heavy that I think it may result in a situation where a thread running the first while when D1.writer is already set, will cause the other thread to starve...

Suppose that Thread 1 sets D1.writer then moves to the remaining code. Thread 2 will then enter the first while loop waiting for D1.writer to become null. It is not guaranteed that Thread 2 will not be the only one thread to aquire D1 monitor for a while, because as soon as it gets out of the "own" method, it will again enter in a race with other thread to get D1 monitor and may acquire it (this is why having such intensive while on a synchronized method is a bad idea). I dont think "synchronized" keyword guarantees a fair sharing of the lock among racing Thread. What do you think?

[admin]

Yes, "synchronized" doesn't guarantee a fair sharing of the lock among racing Thread. Fair sharing of locks depends a lot on how the actual code in written and what it is doing.
In the code given in this question however, livelock is not possible because thread t1 doesn't try to reacquire the lock to d1 once it releases the lock. So, there is only one thread that is in contention to acquire d1's lock (ie. t2) after t1 releases its lock.

[dameest]

In the code given in this question however, livelock is not possible because thread t1 doesn't try to reacquire the lock to d1 once it releases the lock. So, there is only one thread that is in contention to acquire d1's lock (ie. t2) after t1 releases its lock.

There are actually 2 synchronized methods in Data class: "own" and "release". The case I described may occur when t1 tries to run the "release" method while t2 is busy with the "own" method.

[admin]

Ah right, I see your point. This case is not considered in the answer. It should be fixed.
thank you for your feedback!