More on Thread Safety CSE451 Andrew Whitaker

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

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

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

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

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; } This is unnecessary! No need to synchronize on non-shared state.

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;

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

Concurrent State in Java Immutable Private, Mutable Shared, Mutable Strings String StringBuilder StringBuffer Lists Collections.unmodifableList ArrayList, LinkedList Vector Methods are not synchronized All methods are synchronized

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.

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 reachable mutable state must be synchronized

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

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

Another Example: AspectRatio

Linked List Example