19
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

Sharing Objects Synchronization Atomicity Specifying critical sections Memory visibility One thread’s modification seen by the other Visibility

Embed Size (px)

Citation preview

Page 1: Sharing Objects  Synchronization  Atomicity  Specifying critical sections  Memory visibility  One thread’s modification seen by the other  Visibility

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

Page 2: Sharing Objects  Synchronization  Atomicity  Specifying critical sections  Memory visibility  One thread’s modification seen by the other  Visibility

Example

Page 3: Sharing Objects  Synchronization  Atomicity  Specifying critical sections  Memory visibility  One thread’s modification seen by the other  Visibility

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

Page 4: Sharing Objects  Synchronization  Atomicity  Specifying critical sections  Memory visibility  One thread’s modification seen by the other  Visibility

Stale data – Example

Page 5: Sharing Objects  Synchronization  Atomicity  Specifying critical sections  Memory visibility  One thread’s modification seen by the other  Visibility

Fixed example

Page 6: Sharing Objects  Synchronization  Atomicity  Specifying critical sections  Memory visibility  One thread’s modification seen by the other  Visibility

Locking and visibility Use locking for visibility other than mutual

exclusion

Page 7: Sharing Objects  Synchronization  Atomicity  Specifying critical sections  Memory visibility  One thread’s modification seen by the other  Visibility

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();

Page 8: Sharing Objects  Synchronization  Atomicity  Specifying critical sections  Memory visibility  One thread’s modification seen by the other  Visibility

Volatile variables (contd.)volatile int x = 0; x++;

Volatile variables Visibility

Locking Visibility and atomicity

Page 9: Sharing Objects  Synchronization  Atomicity  Specifying critical sections  Memory visibility  One thread’s modification seen by the other  Visibility

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>(); }

Page 10: Sharing Objects  Synchronization  Atomicity  Specifying critical sections  Memory visibility  One thread’s modification seen by the other  Visibility

Escape of internal mutable states Class UnsafeStates { private String[] states = …. public String[] getStates() { return states; } }

Passing to alien methods

Page 11: Sharing Objects  Synchronization  Atomicity  Specifying critical sections  Memory visibility  One thread’s modification seen by the other  Visibility

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

Page 12: Sharing Objects  Synchronization  Atomicity  Specifying critical sections  Memory visibility  One thread’s modification seen by the other  Visibility

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

Page 13: Sharing Objects  Synchronization  Atomicity  Specifying critical sections  Memory visibility  One thread’s modification seen by the other  Visibility

Example for stack confinement

Page 14: Sharing Objects  Synchronization  Atomicity  Specifying critical sections  Memory visibility  One thread’s modification seen by the other  Visibility

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)

Page 15: Sharing Objects  Synchronization  Atomicity  Specifying critical sections  Memory visibility  One thread’s modification seen by the other  Visibility

Safe publication

Page 16: Sharing Objects  Synchronization  Atomicity  Specifying critical sections  Memory visibility  One thread’s modification seen by the other  Visibility

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)

Page 17: Sharing Objects  Synchronization  Atomicity  Specifying critical sections  Memory visibility  One thread’s modification seen by the other  Visibility

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

Page 18: Sharing Objects  Synchronization  Atomicity  Specifying critical sections  Memory visibility  One thread’s modification seen by the other  Visibility

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

Page 19: Sharing Objects  Synchronization  Atomicity  Specifying critical sections  Memory visibility  One thread’s modification seen by the other  Visibility

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