Three Ways Two Threads Break One Field

Problem one is atomicity, and the bytecode gives it away.

counter++ looks like one thing. Ask the compiler:

0: getstatic     #7    // read c
3: iconst_1            // push 1
4: iadd                // add
5: putstatic     #7    // write c

Read, change, write. Three steps with two gaps in them, and a thread can be paused in either gap.

That is a race condition: the answer depends on the order two threads happen to interleave, and nothing in your code decides that order.

Problem two is visibility, and it is not about speed.

A processor core has its own caches. A thread reading a field in a tight loop can keep reading a cached copy and never go back to main memory. The compiler is also allowed to notice that nothing inside the loop changes flag and read it once before the loop starts.

Both are legal, because Java only promises that a single thread sees its own actions in order. Between threads, nothing is promised unless you ask.

volatile is how you ask.

static volatile boolean flag = false;

writer set marked = true
reader2 stopped after 485899624 spins

The same loop, one keyword, and now it stops. A volatile write goes to main memory and every later volatile read of that field sees it.

volatile also fixes problem three. Reads and writes are not allowed to be moved across a volatile access, so anything written before a volatile write is visible to anything that reads it after.

So the three problems and their fixes:

A lock fixes all three. volatile fixes two. That is the whole reason both exist.

Answer from memory before opening the explanation. Then compare your rule with the answer and revisit the example if they differ.

1. Why does `counter++` lose updates when two threads run it?

   Show the answer

   Because it is three instructions, not one. The bytecode for c++ is:

   getstatic read the current value, then iconst_1 and iadd to add one, then putstatic to write it back.

   Read, change, write. Two threads can both read 5, both work out 6, and both write 6. Two increments happened and the counter went up by one.

   Verified over five runs: 123267, 115782, 111996, 114211, 107227, where 200000 was wanted. Different every time, and nothing throws.

2. A thread spins on `while (!flag)` and another thread sets `flag = true`. Why might the first one never stop?

   Show the answer

   Because nothing promised it would ever look again.

   Each processor core has its own caches, and a thread reading the same field in a tight loop can keep reading a cached copy. The compiler is also allowed to notice that the loop body never changes flag and hoist the read out of the loop entirely.

   Verified: with a plain boolean, the reader was still spinning two seconds after the write. With volatile, it stopped.

   This one is worse than lost updates, because it is not a wrong number. The thread never finishes at all, and it usually only happens on the machine you do not own.

3. What does `volatile` fix, and what does it not?

   Show the answer

   Fixes: visibility and ordering. A write to a volatile field is seen by every thread that reads it afterwards, and the compiler and processor may not move other reads and writes across it.

   Does not fix: anything made of several steps. volatile int c; c++; is still read, change, write, and two threads can still interleave those three. Every value read is fresh and updates are still lost.

   So volatile is right for a flag that one thread writes and others read. It is wrong for a counter, and reaching for it there is one of the most common mistakes in concurrent Java.

Write each solution in VS Code, predict its result, and then run the checks. Reading an example does not replace implementing it.

4 exercises100 pointsabout 95 minutes

public class FiveRuns {
    static int counter = 0;

    public static void main(String[] args) throws Exception {
        // TODO: two threads, 100_000 increments each. Run the whole thing five times.
        //       Print all five totals.
        // TODO: try it with 100 increments each instead. What happens, and why is
        //       that more dangerous than the first result?
        // TODO: put a print inside the loop and run again. What changes?
        // TODO: look at the bytecode for counter++ with javap -c
    }
}

public class NeverSaw {
    static boolean plain = false;
    static volatile boolean marked = false;

    public static void main(String[] args) throws Exception {
        // TODO: a thread spinning on while (!plain). Another sets plain = true
        //       after 300 ms. Wait two seconds. Is the reader still alive?
        // TODO: the same with the volatile field. Compare.
        // TODO: add a System.out.println inside the spin loop and try the plain
        //       version again. Does it stop now? Why is that infuriating?
        // TODO: say why this is NOT fixed by synchronizing the counter
    }
}

public class NotEnough {
    static volatile int counter = 0;

    public static void main(String[] args) throws Exception {
        // TODO: two threads, 100_000 increments each, on the VOLATILE counter.
        //       Predict the total. Run it five times.
        // TODO: compare with the non-volatile version from the first exercise.
        //       Is it closer to correct? Is it correct?
        // TODO: now fix it properly with synchronized and run five more times
        // TODO: write one line each on what volatile fixes and what it does not
    }
}

import java.util.*;
import java.util.stream.*;

public class Rebuilt {
    public static void main(String[] args) throws Exception {
        // TODO: reproduce the Section 11.6 failure with a parallel stream.
        //       Run it five times and record all five sizes.
        // TODO: now reproduce the SAME failure with plain threads and no streams
        // TODO: look at what ArrayList.add does and name the steps
        // TODO: fix it three ways: a synchronized list, a collect, and a
        //       per thread list merged at the end. Time all three.
    }
}