Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<blockquote> <ul> <li>Are not return and assignment atomic operations in Java?</li> </ul> </blockquote> <p>Yes they are atomic (in some cases at least), but atomicity is not the only issue. Another important issue is whether the action of a write to an attribute by one thread is guaranteed to be visible to a following read for the same attribute made by a different thread.</p> <ul> <li><p>When the reads and writes are in the same thread, the read is guaranteed to see the earlier write.</p></li> <li><p>When the reads and writes are in different threads, the read is only guaranteed to see the earlier write if the two threads synchronize properly ... or if the attribute is declared as <code>volatile</code>.</p></li> </ul> <p>Note that primitive locks/mutexes are not the only way to synchronize.</p> <blockquote> <ul> <li>Since properties might not necessarily be interrelated, it does not always make sense to synchronize with the same lock. How to organize the locking structure?</li> </ul> </blockquote> <p>It makes sense to use multiple locks if (and only if) lock contention is likely. In your example, lock contention is only likely to be an issue if some <code>Doggie</code> instance receives a very high rate of get and/or set operations.</p> <blockquote> <ul> <li>Is it better to go with the intrinsic lock or a private Object lock pattern?</li> </ul> </blockquote> <p>It depends. If your application is going use the <code>Doggie</code> object's primitive lock, then you might get lock contention or even unintended locking out of get and set operations. In that case a private lock might be advisable. Otherwise, a private lock is an unnecessary overhead.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload