java concurrency in pactice_Chapter 3

 Sharing Objects

 

section 3.1

1. There is no guarantee that operations in one thread will be performed in the order given by the program, as long as the reordering is not detectable from within that thread  even if the reordering is apparent to other threads.
2. For setter and getter,synchronizing only the setter would not be sufficient: threads calling get would still be able to see stale values.
3. Even if you don't care about stale values, it is not safe to use shared mutable long and double variables in multithreaded programs unless they are declared volatile or guarded by a lock. Because the Java Memory Model requires fetch and store operations to be atomic, but for nonvolatile long and double variables, the JVM is permitted to treat a 64-bit read or write as two separate 32-bit operations. If the reads and writes occur in different threads, it is therefore possible to read a nonvolatile long and get back the high 32 bits of one value and the low 32 bits of another.

4. Locking is not just about mutual exclusion; it is also about memory visibility. To ensure that all threads see the most up-to-date values of shared mutable variables, the reading and writing threads must synchronize on a common lock.

5. Use volatile variables only when they simplify implementing and verifying your synchronization policy; avoid using volatile variables when veryfing correctness would require subtle reasoning about visibility. Good uses of volatile variables include ensuring the visibility of their own state, that of the object they refer to, or indicating that an important lifecycle event (such as initialization or shutdown) has occurred.

6. You can use volatile variables only when all the following criteria are met:

   • Writes to the variable do not depend on its current value, or you can ensure that only a single thread ever updates the value;

   • The variable does not participate in invariants with other state variables; and

   • Locking is not required for any other reason while the variable is being accessed.

7. Locking can guarantee both visibility and atomicity; volatile variables can only guarantee visibility.

section 3.2

 

1. Do not allow the this reference to escape during construction.

2. A common mistake that can let the this reference escape during construction is to start a thread from a constructor.Calling an overrideable instance method (one that is neither private nor final) from the constructor can also allow the this reference to escape.

3. Thread Confinement:Ad-hoc Thread Confinement, Stack Confinement??

section 3.3

 

1. An object is immutable if:

   • Its state cannot be modifled after construction;

   • All its flelds are final;^[12] and

   • It is properly constructed (the this reference does not escape during construction).

2. Just as it is a good practice to make all fields private unless they need greater visibility [EJ Item 12], it is a good practice to make all fields final unless they need to be mutable.

3.