More on Thread Safety

1. More on Thread Safety CSE451 Andrew Whitaker

2. Safety Rule #1 • All shared, mutable state must be properly synchronized • Usually with a synchronized block or method

3. Rule #2 • Compound actions must be protected by a single lock • Often, we talk about protecting an invariant with a single lock • e.g., aspect ratio remains fixed

4. Why Not Make Every Method Synchronized? • Synchronization has a performance cost • Each lock access is a cache miss • Synchronization limits parallelism • Rampant synchronization leads to deadlock Amount of synchronization Available parallelism

5. Safety Rule #1, Revised • All shared, mutable state must be properly synchronized • Usually with a synchronized block or method • Corollaries: • Do not synchronize for non-shared state • Accessed by a single thread • Do not synchronize on immutable state

6. This is unnecessary! No need to synchronize on non-shared state. public class Foo { public int addSix(int arg) { synchronized (this) { // grab “this” lock arg += 6; } // release “this” lock return arg; } }

7. Immutable state does not require synchronization! // Thread-safe public class Integer { private final int x; public Integer(int arg) { this.x = arg; } // hold “this” lock during entire method public synchronized int get() { // hold “this” return x; } }

8. Thread-safe Objects • aString is thread-safe for any run method • The reference is immutable (final) • The String class is immutable public class Bar extends Thread { private final String aString = “Hello”; public void run() { // .. Stuff in here… } }

9. Concurrent State in Java Methods are not synchronized All methods are synchronized

10. Documentation Diving: Java.util.ArrayList Note that this implementation is not synchronized. If multiple threads access an ArrayList instance concurrently, and at least one of the threads modifies the list structurally, it must be synchronized externally. This is typically accomplished by synchronizing on some object that naturally encapsulates the list. If no such object exists, the list should be "wrapped" using the Collections.synchronizedList method.

11. Be Careful with Thread-safe Data Structures public class MyClass extends Thread { // Always thread-safe private static final Vector<String> someStrings = new Vector<String>(); // Not necessarily thread safe: StringBuilder is mutable private static final Vector<StringBuilder> someMoreStrings = new Vector<StringBuilder>(); public void run () { // do something with the lists of strings… } } All reachablemutablestate must be synchronized

12. Using Non-Thread-Safe Objects with Threads public class MyClass extends Thread { // This data structure is not thread-safe private static final List<String> someStrings = new ArrayList<String>(); public void run () { // But, that’s OK if all accesses are // synchronized on a single lock synchronized(someStrings) { someStrings.add(“fubar”); } } }

13. Example from Project #1 • Do the execcounts counters require synchronized access? • Yes: • The counters are shared across multiple processes/threads • The counters are mutable • Solution: atomic variables • See Linux /include/asm-i386/atomic.h

14. Another Example: AspectRatio

15. Linked List Example