Upload
darleen-lawson
View
215
Download
2
Embed Size (px)
Citation preview
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
Example
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
Stale data – Example
Fixed example
Locking and visibility Use locking for visibility other than mutual
exclusion
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();
Volatile variables (contd.)volatile int x = 0; x++;
Volatile variables Visibility
Locking Visibility and atomicity
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>(); }
Escape of internal mutable states Class UnsafeStates { private String[] states = …. public String[] getStates() { return states; } }
Passing to alien methods
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
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
Example for stack confinement
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)
Safe publication
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)
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
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
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