1. Sharing Objects  Synchronization  Atomicity  Specifying critical sections  Memory visibility  One thread’s modification seen by the other  Visibility  T1: X = 5; print(X); will result in 5.  T1: X = 5; T2: print(X); may or may not print 5.  Use synchronization

2. Example

3. Problems with the example  Infinite loop  ready not visible to ReaderThread  Reordering  Not detectable from within the thread  Apparent to other threads  Insufficiently synchronized multithreaded programs  Reasoning on order of memory actions can be incorrect  Stale data  Not all-or-nothing  Unexpected exceptions  Corrupted data structures  Inaccurate computations  Infinite loops

4. Stale data – Example

5. Fixed example

6. Locking and visibility  Use locking for visibility other than mutual exclusion

7. Volatile variables  Weaker form of synchronization  Updates propagated to other threads  Ensures  Variables are not cached in registers  Not reordered with other memory operations  Ensures visibility for other variables  Not recommended however volatile boolean asleep; … while(!asleep) doSomething();

8. Volatile variables (contd.) volatile int x = 0; x++;  Volatile variables  Visibility  Locking  Visibility and atomicity

9. Publication and escape  Object available to code outside current scope  Storing a reference  Returning from a non-private method  Passing it to a method in another class  Escape  Publish when it should not have been  public static Set knownSecrets; public void initialize() { knownSecrets = new HashSet (); }

10. Escape of internal mutable states  Class UnsafeStates { private String[] states = …. public String[] getStates() { return states; } }  Passing to alien methods

11. Safe construction practices  Do not allow this to escape during construction  Start thread from a constructor  Incomplete object seen by thread  Create but not start.  Private constructor and public factory method

12. Thread confinement  Ad-hoc thread confinement  Implementation takes care of confinement  Fragile  Stack confinement  Reachable through local variables  See next slide for example  Maintenance harder  ThreadLocal (Language support)  ThreadLocal approx. equals Map  Port single-threaded application to multithreaded  Same caution as with global variables

13. Example for stack confinement

14. Immutability  Mutability  Stale values, losing updates, inconsistent state  Immutable  State cannot be changed after construction  Inherently thread-safe  Reasoning about state of immutable objects – trivial  Passable to untrusted code  Definition (in Java)  State cannot be modified after construction  All fields are final  Properly constructed (this does not escape)

15. Safe publication

16. Immutable objects and initialization safety  Object reference becomes visible to another thread  State of that object is not necessarily visible  Synchronization is needed  Immutable objects  Synchronization not needed (in Java)

17. Safe publication idioms  Reference to the object and object’s state made visible simultaneously  Safe publication using  Initializing object reference from a static initializer  Class initialization time  Storing reference to it into a volatile field (or AtomicReference)  Storing reference into a final field  Storing reference to a field that is properly guarded by a lock

18. Safe publication (contd.)  Effectively immutable  Not technically immutable  State will not be modified after publication  No need for synchronization  Improve performance  Publication requirements  Immutable objects published via any mechanism  Effectively immutable objects must be safely published  Mutable objects – safely published and  Guarded by a lock or  Thread-safe

19. Sharing objects safely  What to do with an object reference  Acquire a lock before using it?  Can state be modified?  Is it read-only object?  Policies for using and sharing objects  Thread-confined  Shared read-only  Immutable and effectively immutable  No addl. synchronization  Shared thread-safe  No addl. synchronization by user  Guarded  Accessed only with a specific lock