Sharing Objects

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<Secret> knownSecrets; public void initialize() { knownSecrets = new HashSet<Secret>(); }

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<T> approx. equals Map<Thread, T> • 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 (thisdoes 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