A boolean flag is updated by a writer inside a synchronized block but read by a worker loop without synchronization. Why might the worker never see the update, and how do the synchronized memory effects explain the fix?

## The bug, concretely ```java class Worker { private boolean stop = false; // shared flag, NOT volatile private final Object lock = new Object(); void requestStop() { synchronized (lock) { stop = true; } // writer: synchronized } void run() { while (!stop) { // reader: NOT synchronized // do work } } } ``` Another thread calls `requestStop()`, but `run()` may loop forever. Why? ### Why the reader can spin forever Without any synchronization or `volatile` on the read, the Java Memory Model places **no constraint** that the reading thread ever reloads `stop` from main memory. A real JIT compiler may **hoist** the read out of the loop — effectively rewriting `while (!stop)` into `if (!stop) while (true)` — because nothing in the reader's own thread changes `stop`, so the compiler assumes it is constant. The CPU may also keep `stop` in a register or in the core's cache. The writer flips `stop` to `true` and even flushes it (its `synchronized` release publishes the write), but the reader has no reason to look again. Result: an infinite loop on a stale value. This is a **visibility bug**, and it is one of the most common real-world concurrency defects. ### What the writer's synchronized actually did The writer's `synchronized (lock) { stop = true; }` does perform a **release barrier** on exit: `stop = true` is flushed and made available. But a flush is only half of a handshake. The JMM's **monitor-lock happens-before rule** says: an unlock happens-before a *subsequent lock of the same monitor*. The guarantee of seeing the write exists **only for a thread that performs that matching acquire.** Our reader never acquires `lock`, so there is **no happens-before edge** between the writer's release and the reader's read — hence no guarantee. ### The fix via synchronized (acquire on the read) ```java void run() { while (true) { synchronized (lock) { if (stop) break; } // do work } } ``` Now each loop iteration performs a **monitor acquire** on the same `lock`. The acquire barrier **invalidates the cached copy and re-reads** `stop` from main memory, so it observes the value the writer flushed. The acquire/release pair establishes the happens-before edge, and the loop terminates. ### The simpler fix via volatile ```java private volatile boolean stop = false; ``` A `volatile` read behaves like a lightweight **acquire** and a `volatile` write like a lightweight **release**. Each `while (!stop)` read is now guaranteed to see the latest write, with no lock and no mutual exclusion needed (a single boolean flag needs visibility, not atomicity-of-a-compound-action, so `volatile` suffices). This is the idiomatic fix for a simple stop flag. ### The general rule this illustrates **Both ends of a shared mutable variable must use the same synchronization.** Synchronizing only the writer (or only the reader) breaks the acquire/release pairing and loses the guarantee. The memory effects of `synchronized` are a *handshake*: the writer's release flushes, but the reader must perform a matching acquire to be guaranteed to see it. Choose `synchronized` (mutual exclusion + visibility) when you also need atomicity over a compound operation; choose `volatile` (visibility only) for a simple flag. ### Define the terms used - **Stale read:** reading an out-of-date value because the thread used a cached copy instead of re-reading shared memory. - **Hoisting:** a compiler optimization that moves an invariant read out of a loop, assuming it cannot change. - **Happens-before:** the JMM relation guaranteeing one action's effects are visible to and ordered before another; created here only by same-monitor unlock→lock. - **Release / acquire barrier:** the flush-on-exit and invalidate-on-entry effects of monitor release/acquire (and of volatile write/read).