Reading 21: Thread Safety

Unlike local variables, static variables are not automatically thread confined.

If you have static variables in your program, then you have to make an argument that only one thread will ever use them, and you have to document that fact clearly. Better, you should eliminate the static variables entirely.

Here’s an example that follows the singleton design pattern, which uses a private static variable:

// This class has a race condition in it.
public class PinballSimulator {

    private static PinballSimulator simulator = null;
    // invariant: there should never be more than one PinballSimulator
    //            object created

    private PinballSimulator() {
        System.out.println("created a PinballSimulator object");
    }

    // factory method that returns the sole PinballSimulator object,
    // creating it if it doesn't exist
    public static PinballSimulator getInstance() {
        if (simulator == null) {
            simulator = new PinballSimulator();
        }
        return simulator;
    }
}

This class has a race in the getInstance() method – two threads could call it at the same time and end up creating two copies of the PinballSimulator object, which we don’t want.

To fix this race using the thread confinement approach, you would specify that only a certain thread (maybe the “pinball simulation thread”) is allowed to call PinballSimulator.getInstance(). The risk here is that Java won’t help you guarantee this.

In general, static variables are very risky for concurrency. They might be hiding behind an innocuous function that seems to have no side-effects or mutations. Consider this example:

// is this method threadsafe?
/**
 * @param x integer to test for primeness; requires x > 1
 * @return true if x is prime with high probability
 */
public static boolean isPrime(int x) {
    if (cache.containsKey(x)) return cache.get(x);
    boolean answer = BigInteger.valueOf(x).isProbablePrime(100);
    cache.put(x, answer);
    return answer;
}

private static Map<Integer,Boolean> cache = new HashMap<>();

This function stores the answers from previous calls in case they’re requested again. This technique is called memoization, and it’s a sensible optimization for slow functions like exact primality testing. But now the isPrime method is not safe to call from multiple threads, and its clients may not even realize it. The reason is that the HashMap object referenced by the static variable cache is shared by all calls to isPrime(), and HashMap is not threadsafe. If multiple threads mutate the map at the same time, by calling cache.put(), then the map can become corrupted in the same way that the bank account became corrupted in the last reading. If you’re lucky, the corruption may cause an exception deep in the hash map, like a Null­Pointer­Exception or Index­OutOfBounds­Exception. But it also may just quietly give wrong answers, as we saw in the bank account example.

public static void main(String[] args) {
    new Thread(new Runnable() { // create a thread using an
        public void run() {     // anonymous Runnable
            computeFact(99);
        }
    }).start();
    computeFact(100);
}

public static void main(String[] args) {
    computeFact(98);
    Thread t = new Thread(new Runnable() {
        public void run() {
            computeFact(99);
        }
    });
    computeFact(100);
    t.start();
}

public class PinballSimulator {

    private static PinballSimulator simulator = null;
    // invariant: there should never be more than one PinballSimulator
    //            object created

    public static PinballSimulator getInstance() {
1)      if (simulator == null) {
2)          simulator = new PinballSimulator();
        }
3)      return simulator;
    }

    ...
}

public class C {
    public static void main(String[] args) {
        new Thread(new Runnable() {
            public void run() {
                threadA();
            }
        }).start();

        new Thread(new Runnable() {
            public void run() {
                threadB();
            }
        }).start();
    }

    private static String name = "Napoleon Dynamite";
    private static int cashLeft = 150;

    private static void threadA() {
        int amountA = 20;
        cashLeft = spend(amountA);
    }

    private static void threadB() {
        int amountB = 30;
        cashLeft = spend(amountB);
    }

    private static int spend(int amountToSpend) {
        return cashLeft - amountToSpend;
    }
}

Returning to our PinballSimulator, suppose we have a mutable rep to model the balls, flippers, bumpers, etc. in an instance of the simulator:

public class PinballSimulator {

    private final List<Ball> ballsInPlay;
    private final Flipper leftFlipper;
    private final Flipper rightFlipper;
    // ... other instance fields...

    // ... instance observer and mutator methods ...
}

Instance variables are not automatically thread confined, even if they are declared private. If we want to argue that the PinballSimulator ADT is threadsafe, we cannot use confinement. We don’t know whether or how clients have created aliases to a PinballSimulator instance from multiple threads. If they have, then concurrent calls to methods of this class will make concurrent access to its fields and their values.

We’ll return to the question of thread safety arguments for data types later in this reading, and in the next reading.

In the previous reading, we used anonymous Runnable instances to start new threads. This is common, but it also complicates the confinement of local variables. Let’s look at how that can happen.

public class PinballSimulator {
    
    private int highScorehighScore;
    // ...
    
    public void simulate() {
        final int numberOfLivesnumberOfLives = 3;
        List<Ball> ballsInPlayballsInPlay = new ArrayList<>();
        
        new Thread(new Runnable() {
            public void run() {
                ballsInPlay.add(new Ball());numberOfLives -= 1;System.out.println(numberOfLives);highScore += 1000;// TODO // ERROR
            }
        }).start();
    }
}

In a system where you create and start new threads, sharing fields and local variables with inner Runnable instances is common. You will need to use one of the upcoming strategies to ensure that sharing those non-confined references and objects is safe.

So in order to be confident that an immutable data type is threadsafe without locks, we need a stronger definition of immutability. A type is threadsafe immutable if it has:

• no mutator methods
• all fields declared private and final
• no representation exposure
• no mutation whatsoever of mutable objects in the rep – not even beneficent mutation

If you follow these rules, then you can be confident that your immutable type will also be threadsafe.

The collection interfaces in Java – List, Set, Map – have basic implementations that are not threadsafe. The implementations of these that you’ve been used to using, namely ArrayList, HashMap, and HashSet, cannot be used safely from more than one thread.

Fortunately, just like the Collections API provides wrapper methods that make collections immutable, it provides another set of wrapper methods to make collections threadsafe, while still mutable.

These wrappers effectively make each method of the collection atomic with respect to the other methods. An atomic action effectively happens all at once – it doesn’t interleave its internal operations with those of other actions, and none of the effects of the action are visible to other threads until the entire action is complete, so it never looks partially done.

Now we see a way to fix the isPrime() method we had earlier in the reading:

private static Map<Integer,Boolean> cache =
                Collections.synchronizedMap(new HashMap<>());

A few points here.

Don’t circumvent the wrapper. Make sure to throw away references to the underlying non-threadsafe collection, and access it only through the synchronized wrapper. That happens automatically in the line of code above, since the new HashMap is passed only to synchronizedMap() and never stored anywhere else. (We saw this same warning with the unmodifiable wrappers: the underlying collection is still mutable, and code with a reference to it can circumvent immutability.)

Iterators are still not threadsafe. Even though method calls on the collection itself (get(), put(), add(), etc.) are now threadsafe, iterators created from the collection are still not threadsafe. So you can’t use iterator(), or the for loop syntax:

List<String> list = ...;
for (String s: list) { ... } // not threadsafe, even if list is a synchronized list wrapper

The solution to this iteration problem will be to acquire the collection’s lock when you need to iterate over it, which we’ll talk about in a future reading.

Finally, atomic operations aren’t enough to prevent races: the way that you use the synchronized collection can still have a race condition. Consider this code, which checks whether a list has at least one element and then gets that element:

if ( ! list.isEmpty()) { String s = list.get(0); ... }

Even if you make list into a synchronized list, this code still may have a race condition, because another thread may remove the element between the isEmpty() call and the get() call.

Even the isPrime() method still has potential races:

if (cache.containsKey(x)) return cache.get(x);
boolean answer = BigInteger.valueOf(x).isProbablePrime(100);
cache.put(x, answer);

The synchronized map ensures that containsKey(), get(), and put() are now atomic, so using them from multiple threads won’t damage the rep invariant of the map. But those three operations can now interleave in arbitrary ways with each other, which might break the invariant that isPrime needs from the cache: if the cache maps an integer x to a value f, then x is prime if and only if f is true. If the cache ever fails this invariant, then we might return the wrong result.

So we have to argue that the races between containsKey(), get(), and put() don’t threaten this invariant. The code has two risky paths:

1. Suppose containsKey(x) returns true, but then another thread mutates the cache before the get(x) call. This is not harmful because we never remove items from the cache – once it contains a result for x, it will continue to do so.
2. Alternatively, suppose containsKey(x) returns false, but another thread mutates the cache before put(x, ...). It may end up that the two threads both test the primeness of the same x at the same time, and both will race to call put() with the answer. But both of them should call put(x, answer) with the same value for answer, so it doesn’t matter which one wins the race – the result will be the same.

The need to make these kinds of careful arguments about safety – even when you’re using threadsafe data types – is the main reason that concurrency is hard.

public class Building {
    private final String buildingName;
    private int numberOfFloors;
    private final int[] occupancyPerFloor;
    private final List<String> companyNames = Collections.synchronizedList(new ArrayList<>());
    private final Set<String> roomNumbers = new HashSet<>();
    private final Set<String> floorplan = Collections.synchronizedSet(roomNumbers);
    ...
}

List<String> subjects = new ArrayList<>(List.of("6.045", "6.031", "6.813"));
for (String subject : subjects) {
    if (subject.startsWith("6.")) {
        subjects.remove(subject);
    }
}

Let’s see some examples of how to make thread safety arguments for a data type.

Remember our four approaches to thread safety: confinement, immutability, threadsafe data types, and synchronization. Since we haven’t talked about synchronization in this reading, we won’t use it in the thread safety arguments below.

We won’t use confinement either. Confinement is not usually an option when we’re making an argument just about a data type, because you have to know what threads exist in the system and what objects they’ve been given access to. If the data type creates its own set of threads, then you can talk about confinement with respect to those threads. Otherwise, the threads are coming in from the outside, carrying client calls, and the data type may have no guarantees about which threads have references to what. So confinement isn’t a useful argument in that case. Usually we use confinement at a higher level, talking about the system as a whole and arguing why we don’t need thread safety for some of our modules or data types, because they won’t be shared across threads by design.

So we’ll focus on thread safety arguments that appeal to immutability and threadsafe data types.

We also have to avoid rep exposure, and document our argument for safety from rep exposure. Rep exposure is bad for any data type, since it threatens the data type’s rep invariant. It’s similarly fatal to thread safety.

For example, here is a good argument that appeals to immutability:

/** MyString is an immutable data type representing a string of characters. */
public class MyString {
    private final char[] a;
    // Thread safety argument:
    //    This class is threadsafe immutable:
    //    - a is private and final
    //    - a points to a mutable char array, but that array is encapsulated
    //      in this object, not shared with any other object or exposed to a
    //      client, and is never mutated

Here’s another rep for MyString that requires a little more care in the argument. Even though the rep is not exposed, it is aliased with other instances of the type:

/** MyString is an immutable data type representing a string of characters. */
public class MyString {
    private final char[] a;
    private final int start;
    private final int len;
    // Rep invariant:
    //    0 <= start <= a.length
    //    0 <= len <= a.length-start
    // Abstraction function:
    //    AF(a,start,len) = the string of characters a[start],...,a[start+length-1]
    // Thread safety argument:
    //    This class is threadsafe immutable:
    //    - a, start, and len are final
    //    - a points to a mutable char array, which may be shared with other
    //      MyString objects, but they never mutate it
    //    - the array is never exposed to a client

Note that since this MyString rep was designed for sharing the array between multiple MyString objects, we have to ensure that the sharing doesn’t threaten its thread safety. As long as it doesn’t threaten the MyString’s immutability, however, we can be confident that it won’t threaten the thread safety.

Here is an argument that rests on using a threadsafe type in the rep, plus the immutability of the reference to it:

/** Team is a mutable data type representing a team of people. */
public class Team {
    private final Set<String> people = Collections.synchronizedSet(new HashSet<>());
    // Rep invariant:
    //    true
    // Abstraction function:
    //    AF(people) = the group of people whose names are in the set `people` 
    // Thread safety argument:
    //    people is a threadsafe set, and the people variable is unreassignable.

Here are some incorrect thread safety arguments:

/** MyStringBuffer is a threadsafe mutable string of characters. */
public class MyStringBuffer {
    private String text;
    // Rep invariant:
    //   none
    // Abstraction function:
    //   represents the sequence text[0],...,text[text.length()-1]
    // Thread safety argument:
    //   text is a threadsafe immutable String,
    //   so this object is also threadsafe

Why doesn’t this argument work? String is indeed immutable and threadsafe. But the rep itself is not immutable, because the text variable is not final. Indeed text cannot be final in this data type, because we need to be able to reassign it to support mutator operations on the string buffer. So reads and writes of the text variable itself are not threadsafe. This argument is false.

Here’s another broken argument:

public class Graph {
    private final Set<Node> nodes =
                   Collections.synchronizedSet(new HashSet<>());
    private final Map<Node,Set<Node>> edges =
                   Collections.synchronizedMap(new HashMap<>());
    // Rep invariant:
    //    for all x, y such that y is a member of edges.get(x),
    //        x, y are both members of nodes
    // Abstraction function:
    //    represents a directed graph whose nodes are the set of nodes
    //        and whose edges are the set (x,y) such that
    //                         y is a member of edges.get(x)
    // Thread safety argument:
    //    - nodes and edges are final, so those variables are immutable
    //      and threadsafe
    //    - nodes and edges point to threadsafe set and map data types

This is a graph data type, which stores its nodes in a set and its edges in a map. (Quick quiz: is Graph a mutable or immutable data type? What do the final keywords have to do with its mutability?) Graph relies on other threadsafe data types to help it implement its rep – specifically the threadsafe Set and Map wrappers that we talked about above. That prevents some race conditions, but not all, because the graph’s rep invariant includes a relationship between the node set and the edge map. All nodes that appear in the edge map also have to appear in the node set. So there may be code like this:

public void addEdge(Node from, Node to) {
    if ( ! edges.containsKey(from)) {
        edges.put(from, Collections.synchronizedSet(new HashSet<>()));
    }
    edges.get(from).add(to);
    nodes.add(from);
    nodes.add(to);
}

This code has race conditions. There is a crucial moment when the rep invariant is violated, right after the edges map is mutated, but just before the nodes set is mutated. Another operation on the graph might interleave at that moment, discover the rep invariant broken, and return wrong results. Even though the threadsafe set and map data types guarantee that their own add() and put() methods are atomic and noninterfering, they can’t extend that guarantee to interactions between the two data structures. So the rep invariant of Graph is not safe from race conditions. Just using threadsafe-immutable and threadsafe-mutable data types is not sufficient when the rep invariant depends on relationships between objects in the rep.

We’ll have to fix this with synchronization, and we’ll see how in a future reading.

  public void addEdge(Node from, Node to) {
1     if ( ! edges.containsKey(from)) {
2         edges.put(from, Collections.synchronizedSet(new HashSet<>()));
      }
3     edges.get(from).add(to);
4     nodes.add(from);
5     nodes.add(to);
  }

/** MyStringBuffer is a mutable string of characters. */
public class MyStringBuffer {
    private String text;
    // Rep invariant:
    //   none
    // Abstraction function:
    //   represents the sequence text[0],...,text[text.length()-1]
    // Thread safety argument:
    //   text is a threadsafe immutable String,
    //   so this object is also threadsafe

    /** 
     * @return the string represented by this buffer,
     *         with all letters converted to uppercase
     */
    public String toUpperCase() { return text.toUpperCase(); }

    /**
     * @param pos position to insert text into the buffer,
     *            requires 0 <= pos <= length of the current string
     * @param s text to insert
     * Mutates this buffer to insert s as a substring at position pos.
     */
    public void insert(int pos, String s) {
        text = text.substring(0, pos) + s + text.substring(pos);
    }

    /**
     * @return the string represented by this buffer
     */
    public String toString() { return text; }

    /**
     * Resets this buffer to the empty string.
     */
    public void clear() { text = ""; }

    /**
     * @return the first character of this buffer, or "" if this buffer is empty
     */
    public String first() {
        if (text.length() > 0) {
            return String.valueOf(text.charAt(0));
        } else {
            return "";
        }
    }
}

Look again at the code for the exercise above. We might also be concerned that clear and insert could interleave such that a client sees clear violate its postcondition.

Suppose two threads are sharing MyStringBuffer sb representing "z". They run clear and insert concurrently as shown on the right.

Thread A’s assertion will fail, but not because clear violated its postcondition. Indeed, when clear reaches the end of its method body, the postcondition is satisfied.

The real problem is that thread A has not anticipated possible interleaving between clear() and the assert. With any threadsafe mutable type where atomic mutators are called concurrently, some mutation has to “win” by being the last one applied. The result that thread A observed is identical to the execution below, where the mutators don’t interleave at all:

What we demand from a threadsafe data type is that when clients call its atomic operations concurrently, the results are consistent with some sequential ordering of the calls. In this case, clearing and inserting, that means either clear-followed-by-insert, or insert-followed-by-clear. This property is called serializability: for any set of operations executed concurrently, the result (the values and state observable by clients) must be a result given by some sequential ordering of those operations.