{"title":"Happens-Before Relationship","description":"","content":"# Happens-Before Relationship\n\n\"Does Thread B see the value written by Thread A?\" This seemingly simple question has driven many developers to frustration. The answer depends on whether there's a happens-before relationship between the write and the read. Without understanding happens-before, you're guessing whether your concurrent code is correct. With it, you can prove correctness.\n\nThe previous chapter explained why visibility problems exist. This chapter provides the formal tool for reasoning about when visibility is guaranteed. The happens-before relationship is the foundation of the Java Memory Model and similar constructs in other languages. Once you internalize these rules, you can look at any piece of concurrent code and determine exactly which values a read might observe.\n\n---\n\n## What is Happens-Before?\n\nImagine a game of telephone played across time zones. Alice sends a message at noon New York time. Bob receives it at 6pm London time. Did Bob's reception \"happen after\" Alice's sending? In wall-clock time, yes. But what if Alice and Bob have different clocks, or the message took an unpredictable route? We need a reliable way to establish ordering that doesn't depend on physical clocks.\n\nIn concurrent programming, \"happens-before\" is a logical ordering between events, not a temporal one. When we say action A happens-before action B, we mean:\n\n1. **A is visible to B:** All memory effects of A are guaranteed to be visible when B executes\n2. **A precedes B logically:** B can rely on A having completed\n3. **This is guaranteed by the language/runtime:** It's not about wall-clock timing\n\nThe crucial insight: actions without a happens-before relationship may appear in either order, or even simultaneously from each other's perspective. The memory model provides no guarantee about their relative ordering or visibility.\n\n\n```mermaid\nflowchart TD\n subgraph T1[\"Thread 1\"]\n A1[\"x = 1\"]\n A2[\"lock(m)\"]\n A3[\"y = 2\"]\n A4[\"unlock(m)\"]\n A1 --> A2 --> A3 --> A4\n end\n\n subgraph T2[\"Thread 2\"]\n B1[\"lock(m)\"]\n B2[\"read y\"]\n B3[\"read x\"]\n B4[\"unlock(m)\"]\n B1 --> B2 --> B3 --> B4\n end\n\n A4 -.->|\"happens-before
(synchronizes-with)\"| B1\n\n style A4 fill:#69db7c,stroke:#000,color:#000\n style B1 fill:#69db7c,stroke:#000,color:#000\n style A1 fill:#00ceff,stroke:#000,color:#000\n style A3 fill:#ffa94d,stroke:#000,color:#000\n style B2 fill:#ffa94d,stroke:#000,color:#000\n style B3 fill:#00ceff,stroke:#000,color:#000\n```\n\n\nThis diagram shows two threads interacting through a monitor (mutex) `m`. Thread 1 writes `x = 1`, acquires the lock, writes `y = 2`, and releases the lock. Thread 2 then acquires the same lock and reads both variables.\n\nThe dotted arrow shows the happens-before edge created by the unlock-lock pair. Because Thread 1's unlock happens-before Thread 2's lock, and program order within each thread creates happens-before edges, we can trace a chain: `x = 1` → `y = 2` → `unlock(m)` → `lock(m)` → `read y` → `read x`. This chain guarantees Thread 2 sees `y = 2` and `x = 1`.\n\nWithout the lock, there would be no happens-before edge between the threads, and Thread 2 might see stale values for either variable.\n\n---\n\n## Why Happens-Before Matters\n\n### Moving Beyond Intuition\n\nWithout happens-before, concurrent programming is guesswork. Consider this code:\n\n\n```java\n// Thread 1\nx = 42;\n\n// Thread 2\nif (x == 42) {\n System.out.println(\"Saw the answer!\");\n}\n```\n\n\nWill Thread 2 ever print the message? Your intuition says \"if Thread 1 runs first, yes.\" But that intuition fails. Even if Thread 1's write completes first in wall-clock time, Thread 2 might read a cached value. The memory model's answer is precise: \"There is no happens-before relationship, so Thread 2 might or might not see 42.\"\n\nHappens-before transforms vague reasoning into provable guarantees.\n\n### Defining Correctness\n\nA concurrent program is correctly synchronized if all accesses to shared variables are ordered by happens-before relationships. This doesn't mean everything is serialized. It means for every read of a shared variable, there's a happens-before chain from the most recent write.\n\n**Correctly synchronized:**\n\n\n```java\n// Thread 1\nsynchronized (lock) {\n data = computeValue();\n ready = true;\n}\n\n// Thread 2\nsynchronized (lock) {\n if (ready) {\n process(data); // Sees Thread 1's data\n }\n}\n```\n\n\n**Incorrectly synchronized (data race):**\n\n\n```java\n// Thread 1\ndata = computeValue();\nready = true;\n\n// Thread 2\nif (ready) {\n process(data); // Might see partial/stale data!\n}\n```\n\n\n### Interview Relevance\n\nHappens-before is the answer to almost every \"is this thread-safe?\" interview question. Instead of handwaving about timing, you can trace happens-before edges:\n\n\n| Question | Happens-Before Answer |\n|----------|----------------------|\n| \"Will Thread B see this write?\" | \"Only if there's a happens-before edge from the write to the read\" |\n| \"Is volatile enough here?\" | \"Volatile creates happens-before between write and subsequent read of that variable\" |\n| \"Why does double-checked locking need volatile?\" | \"Without volatile, no happens-before from object construction to field reads\" |\n\n\n---\n\n## How Happens-Before Works\n\nThe happens-before relation is defined by a set of rules. Each rule creates happens-before edges in your program's execution.\n\n### Rule 1: Program Order\n\nWithin a single thread, each action happens-before every subsequent action in program order.\n\n\n```java\n// Thread 1\nint a = 1; // Action A\nint b = 2; // Action B\nint c = a + b; // Action C\n\n// A happens-before B, B happens-before C, A happens-before C\n```\n\n\nThis seems obvious, but it's the foundation. Within one thread, code executes in order (from the perspective of happens-before). Note that compilers and CPUs may reorder actual execution, but the observable behavior respects program order within a thread.\n\n\n```mermaid\nflowchart LR\n A[\"a = 1\"]:::primary --> B[\"b = 2\"]:::primary --> C[\"c = a + b\"]:::primary\n\n A -.->|\"hb\"| B\n B -.->|\"hb\"| C\n A -.->|\"hb (transitive)\"| C\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n```\n\n\n### Rule 2: Monitor Lock (synchronized)\n\nAn unlock on a monitor happens-before every subsequent lock on that same monitor.\n\n\n```java\n// Thread 1\nsynchronized (monitor) {\n sharedData = 42;\n} // unlock(monitor) here\n\n// Thread 2\nsynchronized (monitor) { // lock(monitor) here\n int x = sharedData; // Sees 42\n}\n```\n\n\nThe unlock at the end of Thread 1's synchronized block happens-before the lock at the start of Thread 2's synchronized block. Combined with program order, this creates a chain that guarantees Thread 2 sees Thread 1's write.\n\n\n```mermaid\nsequenceDiagram\n participant T1 as Thread 1\n participant M as Monitor\n participant T2 as Thread 2\n\n Note over T1,T2: sharedData = 0 initially\n\n T1->>M: lock(monitor)\n T1->>T1: sharedData = 42\n T1->>M: unlock(monitor)\n\n Note right of M: happens-before edge\n\n T2->>M: lock(monitor)\n T2->>T2: read sharedData\n Note right of T2: Guaranteed to see 42\n T2->>M: unlock(monitor)\n```\n\n\n### Rule 3: Volatile Variable\n\nA write to a volatile variable happens-before every subsequent read of that variable.\n\n\n```java\n// Thread 1\nnonVolatileData = 42;\nvolatileFlag = true; // volatile write\n\n// Thread 2\nif (volatileFlag) { // volatile read\n int x = nonVolatileData; // Sees 42!\n}\n```\n\n\nThe magic: the happens-before edge is from the volatile write to the volatile read, but program order extends it. Everything before the volatile write in Thread 1 becomes visible to everything after the volatile read in Thread 2.\n\n\n```mermaid\nflowchart TB\n subgraph T1[\"Thread 1\"]\n W1[\"nonVolatileData = 42\"]\n W2[\"volatileFlag = true\"]\n W1 --> W2\n end\n\n subgraph T2[\"Thread 2\"]\n R1[\"read volatileFlag\"]\n R2[\"read nonVolatileData\"]\n R1 --> R2\n end\n\n W2 -.->|\"happens-before
(volatile)\"| R1\n\n style W2 fill:#69db7c,stroke:#000,color:#000\n style R1 fill:#69db7c,stroke:#000,color:#000\n style W1 fill:#00ceff,stroke:#000,color:#000\n style R2 fill:#00ceff,stroke:#000,color:#000\n```\n\n\n### Rule 4: Thread Start\n\nA call to `Thread.start()` happens-before any action in the started thread.\n\n\n```java\n// Main thread\nsharedData = 42;\nThread t = new Thread(() -> {\n int x = sharedData; // Guaranteed to see 42\n});\nt.start(); // start() happens-before first action in t\n```\n\n\n### Rule 5: Thread Join\n\nAll actions in a thread happen-before another thread returns from `join()` on that thread.\n\n\n```java\n// Thread t\nsharedData = 42;\n\n// Main thread\nt.join(); // Waits for t to finish\nint x = sharedData; // Guaranteed to see 42\n```\n\n\n### Rule 6: Transitivity\n\nIf A happens-before B, and B happens-before C, then A happens-before C.\n\nThis is crucial for building chains across threads:\n\n\n```mermaid\nflowchart LR\n A[\"Thread 1:
x = 1\"]:::primary\n B[\"Thread 1:
volatile y = 1\"]:::green\n C[\"Thread 2:
read y\"]:::green\n D[\"Thread 2:
read x\"]:::primary\n\n A -->|\"program order\"| B\n B -.->|\"volatile hb\"| C\n C -->|\"program order\"| D\n\n A -.->|\"transitive hb\"| D\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\nThe transitive chain A → B → C → D means A happens-before D. Thread 2's read of `x` is guaranteed to see Thread 1's write, even though `x` itself isn't volatile.\n\n### Complete Rules Summary\n\n\n| Rule | From | To |\n|------|------|-----|\n| Program order | Each action | Subsequent action in same thread |\n| Monitor lock | `unlock(m)` | Subsequent `lock(m)` on same monitor |\n| Volatile write/read | `volatile` write | Subsequent `volatile` read of same variable |\n| Thread start | `t.start()` call | First action in thread `t` |\n| Thread join | Last action in `t` | `t.join()` return in calling thread |\n| Thread interrupt | `t.interrupt()` call | `t` detecting interrupt |\n| Finalizer | End of constructor | Start of `finalize()` |\n| Transitivity | A hb B, B hb C | A hb C |\n\n\n---\n\n## Happens-Before in Practice\n\nUnderstanding the rules is one thing. Applying them to real code is another. Let's trace through common patterns.\n\nimport Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem';\n\n### Pattern 1: Safe Publication with volatile\n\n \n\n\n```java\npublic class SafePublication {\n private volatile Config config; // volatile reference\n\n public void initialize() {\n Config temp = new Config();\n temp.setHost(\"localhost\");\n temp.setPort(8080);\n config = temp; // volatile write publishes\n }\n\n public void useConfig() {\n Config c = config; // volatile read\n if (c != null) {\n // Safe: happens-before guarantees we see fully initialized Config\n System.out.println(c.getHost() + \":\" + c.getPort());\n }\n }\n}\n```\n\n\n**Happens-Before Chain:**\n\n1. `temp.setHost()` hb `temp.setPort()` (program order)\n2. `temp.setPort()` hb `config = temp` (program order)\n3. `config = temp` hb `config read` (volatile)\n4. `config read` hb `c.getHost()` (program order)\n\nBy transitivity, `temp.setHost()` hb `c.getHost()`. The reader sees the fully constructed object.\n\n \n\n\n```cpp\n#include \n\nclass SafePublication {\n std::atomic config{nullptr};\n\npublic:\n void initialize() {\n Config* temp = new Config();\n temp->setHost(\"localhost\");\n temp->setPort(8080);\n config.store(temp, std::memory_order_release); // Release\n }\n\n void useConfig() {\n Config* c = config.load(std::memory_order_acquire); // Acquire\n if (c != nullptr) {\n // Safe: acquire-release synchronization\n std::cout << c->getHost() << \":\" << c->getPort() << std::endl;\n }\n }\n};\n```\n\n\n**C++ Memory Order:**\n\n- `release` ensures all prior writes are visible\n- `acquire` ensures subsequent reads see those writes\n- Together they create a happens-before (synchronizes-with) edge\n\n \n\n\n```csharp\nusing System;\nusing System.Threading;\n\npublic class SafePublication\n{\n private volatile Config config; // volatile reference\n\n public void Initialize()\n {\n Config temp = new Config();\n temp.SetHost(\"localhost\");\n temp.SetPort(8080);\n Volatile.Write(ref config, temp); // Release semantics - publishes\n }\n\n public void UseConfig()\n {\n Config c = Volatile.Read(ref config); // Acquire semantics\n if (c != null)\n {\n // Safe: happens-before guarantees we see fully initialized Config\n Console.WriteLine($\"{c.GetHost()}:{c.GetPort()}\");\n }\n }\n}\n```\n\n\n**Happens-Before Chain:**\n\n1. `temp.SetHost()` hb `temp.SetPort()` (program order)\n2. `temp.SetPort()` hb `Volatile.Write` (program order)\n3. `Volatile.Write` hb `Volatile.Read` (volatile semantics)\n4. `Volatile.Read` hb `c.GetHost()` (program order)\n\nBy transitivity, `temp.SetHost()` hb `c.GetHost()`. The reader sees the fully constructed object.\n\n \n\n\n```go\npackage main\n\nimport (\n\t\"fmt\"\n\t\"sync/atomic\"\n)\n\ntype Config struct {\n\thost string\n\tport int\n}\n\ntype SafePublication struct {\n\tconfig atomic.Value // Stores *Config atomically\n}\n\nfunc (s *SafePublication) Initialize() {\n\ttemp := &Config{}\n\ttemp.host = \"localhost\"\n\ttemp.port = 8080\n\ts.config.Store(temp) // Atomic store publishes fully constructed object\n}\n\nfunc (s *SafePublication) UseConfig() {\n\tc := s.config.Load() // Atomic load\n\tif c != nil {\n\t\tcfg := c.(*Config)\n\t\t// Safe: happens-before guarantees we see fully initialized Config\n\t\tfmt.Printf(\"%s:%d\\n\", cfg.host, cfg.port)\n\t}\n}\n```\n\n\n**Happens-Before Chain:**\n\n1. `temp.host = \"localhost\"` hb `temp.port = 8080` (program order)\n2. `temp.port = 8080` hb `config.Store(temp)` (program order)\n3. `config.Store(temp)` hb `config.Load()` (atomic store-load on same Value)\n4. `config.Load()` hb `cfg.host` access (program order)\n\nGo's `atomic.Value` provides happens-before between Store and subsequent Load operations. This is explicitly stated in Go's memory model documentation.\n\n**Alternative using atomic.Pointer (Go 1.19+):**\n\n\n```go\npackage main\n\nimport \"sync/atomic\"\n\ntype SafePublicationModern struct {\n\tconfig atomic.Pointer[Config]\n}\n\nfunc (s *SafePublicationModern) Initialize() {\n\ttemp := &Config{host: \"localhost\", port: 8080}\n\ts.config.Store(temp) // Type-safe atomic store\n}\n\nfunc (s *SafePublicationModern) UseConfig() *Config {\n\treturn s.config.Load() // Type-safe atomic load\n}\n```\n\n\n**Key Points:**\n\n- Go's atomic operations provide sequential consistency, which includes happens-before\n- `atomic.Value.Store()` happens-before any subsequent `Load()` that sees the stored value\n- Channel operations also create happens-before edges (send hb receive)\n- `sync.Mutex` Lock/Unlock pairs create happens-before edges\n\n \n\n### Pattern 2: Producer-Consumer with Lock\n\n \n\n\n```java\npublic class ProducerConsumer {\n private final Queue queue = new LinkedList<>();\n private final Object lock = new Object();\n\n public void produce(Task task) {\n task.prepare(); // Preparation work\n\n synchronized (lock) {\n queue.add(task); // Under lock\n } // unlock happens-before consumer's lock\n }\n\n public Task consume() {\n synchronized (lock) {\n Task task = queue.poll();\n return task; // May be null if queue empty\n }\n }\n\n public void consumeAndProcess() {\n Task task = consume(); // Gets task with happens-before\n if (task != null) {\n task.process(); // Safe: sees task.prepare() effects\n }\n }\n}\n```\n\n\n**Happens-Before Chain:**\n\n1. `task.prepare()` hb `queue.add(task)` (program order in producer)\n2. `unlock(lock)` in producer hb `lock(lock)` in consumer (monitor rule)\n3. `queue.poll()` hb `task.process()` (program order in consumer)\n\n \n\n\n```python\nimport threading\nfrom collections import deque\n\nclass ProducerConsumer:\n def __init__(self):\n self.queue = deque()\n self.lock = threading.Lock()\n\n def produce(self, task):\n task.prepare() # Preparation work\n\n with self.lock:\n self.queue.append(task)\n\n def consume(self):\n with self.lock:\n return self.queue.popleft() if self.queue else None\n\n def consume_and_process(self):\n task = self.consume()\n if task is not None:\n task.process() # Safe due to lock synchronization\n```\n\n\n**Python Note:** While Python lacks a formal memory model, the GIL and lock semantics provide similar guarantees in CPython. The lock release/acquire creates a synchronization point.\n\n \n\n\n```csharp\nusing System;\nusing System.Collections.Generic;\nusing System.Threading;\n\npublic class ProducerConsumer\n{\n private readonly Queue queue = new Queue();\n private readonly object lockObj = new object();\n\n public void Produce(Task task)\n {\n task.Prepare(); // Preparation work\n\n lock (lockObj)\n {\n queue.Enqueue(task); // Under lock\n } // Monitor.Exit happens-before consumer's Monitor.Enter\n }\n\n public Task Consume()\n {\n lock (lockObj)\n {\n return queue.Count > 0 ? queue.Dequeue() : null;\n }\n }\n\n public void ConsumeAndProcess()\n {\n Task task = Consume(); // Gets task with happens-before\n if (task != null)\n {\n task.Process(); // Safe: sees task.Prepare() effects\n }\n }\n}\n```\n\n\n**Happens-Before Chain:**\n\n1. `task.Prepare()` hb `queue.Enqueue(task)` (program order in producer)\n2. `Monitor.Exit(lockObj)` in producer hb `Monitor.Enter(lockObj)` in consumer (monitor rule)\n3. `queue.Dequeue()` hb `task.Process()` (program order in consumer)\n\n \n\n\n```go\npackage main\n\nimport \"sync\"\n\ntype Task struct {\n\tdata string\n}\n\nfunc (t *Task) Prepare() {\n\tt.data = \"prepared\"\n}\n\nfunc (t *Task) Process() {\n\t// Use t.data safely\n}\n\ntype ProducerConsumer struct {\n\tqueue []Task\n\tmu sync.Mutex\n}\n\nfunc (pc *ProducerConsumer) Produce(task Task) {\n\ttask.Prepare() // Preparation work\n\n\tpc.mu.Lock()\n\tpc.queue = append(pc.queue, task) // Under lock\n\tpc.mu.Unlock() // Unlock happens-before consumer's Lock\n}\n\nfunc (pc *ProducerConsumer) Consume() *Task {\n\tpc.mu.Lock()\n\tdefer pc.mu.Unlock()\n\n\tif len(pc.queue) == 0 {\n\t\treturn nil\n\t}\n\ttask := pc.queue[0]\n\tpc.queue = pc.queue[1:]\n\treturn &task\n}\n\nfunc (pc *ProducerConsumer) ConsumeAndProcess() {\n\ttask := pc.Consume() // Gets task with happens-before\n\tif task != nil {\n\t\ttask.Process() // Safe: sees task.Prepare() effects\n\t}\n}\n```\n\n\n**Happens-Before Chain:**\n\n1. `task.Prepare()` hb `queue = append(...)` (program order in producer)\n2. `mu.Unlock()` in producer hb `mu.Lock()` in consumer (mutex rule)\n3. `queue[0]` access hb `task.Process()` (program order in consumer)\n\n**Go's happens-before rules for sync.Mutex:**\n\n- For any `sync.Mutex` variable `m`, the n-th call to `m.Unlock()` happens-before the (n+1)-th call to `m.Lock()`\n\n**Alternative using channels (idiomatic Go):**\n\n\n```go\npackage main\n\ntype ChannelProducerConsumer struct {\n\ttasks chan Task\n}\n\nfunc NewChannelPC() *ChannelProducerConsumer {\n\treturn &ChannelProducerConsumer{tasks: make(chan Task, 100)}\n}\n\nfunc (pc *ChannelProducerConsumer) Produce(task Task) {\n\ttask.Prepare()\n\tpc.tasks <- task // Channel send happens-before receive\n}\n\nfunc (pc *ChannelProducerConsumer) ConsumeAndProcess() {\n\ttask := <-pc.tasks // Receives with happens-before guarantee\n\ttask.Process() // Safe: sees all effects from producer\n}\n```\n\n\n**Key Points:**\n\n- `sync.Mutex` Unlock happens-before subsequent Lock on the same mutex\n- Channel send happens-before the corresponding receive completes\n- These are Go's primary mechanisms for establishing happens-before between goroutines\n\n \n\n### Pattern 3: Thread Join\n\n \n\n\n```java\npublic class JoinExample {\n private int result;\n\n public void compute() throws InterruptedException {\n Thread worker = new Thread(() -> {\n // Complex computation\n int computed = heavyComputation();\n result = computed; // Write happens-before join return\n });\n\n worker.start();\n worker.join(); // join() returns after last action in worker\n\n System.out.println(\"Result: \" + result); // Safe to read\n }\n}\n```\n\n\n**Happens-Before Chain:**\n\n1. `result = computed` hb thread termination (program order)\n2. Thread termination hb `join()` return (join rule)\n3. `join()` return hb `println(result)` (program order)\n\n \n\n\n```cpp\n#include \n#include \n\nclass JoinExample {\n int result = 0;\n\npublic:\n void compute() {\n std::thread worker([this]() {\n int computed = heavyComputation();\n result = computed;\n });\n\n worker.join(); // Synchronizes-with thread completion\n\n std::cout << \"Result: \" << result << std::endl; // Safe\n }\n};\n```\n\n\n \n\n\n```csharp\nusing System;\nusing System.Threading;\n\npublic class JoinExample\n{\n private int result;\n\n public void Compute()\n {\n Thread worker = new Thread(() =>\n {\n // Complex computation\n int computed = HeavyComputation();\n result = computed; // Write happens-before join return\n });\n\n worker.Start();\n worker.Join(); // Waits for worker to finish\n\n Console.WriteLine(\"Result: \" + result); // Safe to read\n }\n\n private int HeavyComputation()\n {\n Thread.Sleep(100);\n return 42;\n }\n}\n```\n\n\n**Happens-Before Chain:**\n\n1. `result = computed` hb thread termination (program order)\n2. Thread termination hb `Join()` return (join rule)\n3. `Join()` return hb `Console.WriteLine(result)` (program order)\n\n \n\n\n```go\npackage main\n\nimport (\n\t\"fmt\"\n\t\"sync\"\n)\n\ntype JoinExample struct {\n\tresult int\n}\n\nfunc (j *JoinExample) Compute() {\n\tvar wg sync.WaitGroup\n\n\twg.Add(1)\n\tgo func() {\n\t\tdefer wg.Done()\n\t\t// Complex computation\n\t\tcomputed := heavyComputation()\n\t\tj.result = computed // Write happens-before wg.Done()\n\t}()\n\n\twg.Wait() // Wait() returns after Done() - happens-before edge\n\n\tfmt.Println(\"Result:\", j.result) // Safe to read\n}\n\nfunc heavyComputation() int {\n\t// Simulate work\n\treturn 42\n}\n```\n\n\n**Happens-Before Chain:**\n\n1. `j.result = computed` hb `wg.Done()` (program order)\n2. `wg.Done()` hb `wg.Wait()` return (WaitGroup rule)\n3. `wg.Wait()` return hb `fmt.Println(j.result)` (program order)\n\n**Go's happens-before rules for sync.WaitGroup:**\n\n- A call to `wg.Done()` happens-before the corresponding `wg.Wait()` returns\n\n**Alternative using channels:**\n\n\n```go\nfunc computeWithChannel() int {\n\tresult := make(chan int)\n\n\tgo func() {\n\t\tcomputed := heavyComputation()\n\t\tresult <- computed // Send happens-before receive\n\t}()\n\n\treturn <-result // Receive sees the computed value\n}\n```\n\n\n**Key Points:**\n\n- Go uses `sync.WaitGroup` instead of thread join\n- `wg.Done()` happens-before `wg.Wait()` returns\n- Channel receive happens-before send on same channel completes (for unbuffered)\n- For buffered channels: send hb receive\n\n \n\n### Anti-Pattern: Missing Happens-Before\n\n \n\n\n```java\n// BROKEN: No happens-before between write and read\npublic class BrokenPattern {\n private int data;\n private boolean ready; // NOT volatile!\n\n public void writer() {\n data = 42;\n ready = true;\n }\n\n public void reader() {\n if (ready) {\n // BUG: May see data = 0!\n // No happens-before between data write and this read\n System.out.println(data);\n }\n }\n}\n```\n\n\n**What's Missing:**\n\n- `ready` is not volatile, so there's no happens-before from `ready = true` to `if (ready)`\n- Without that edge, there's no chain connecting `data = 42` to the read of `data`\n- The JMM allows the read to return 0 (or any previous value)\n\n**Fix Options:**\n\n1. Make `ready` volatile\n2. Synchronize both methods on the same lock\n3. Use an `AtomicBoolean`\n\n \n\n---\n\n## Language-Specific Nuances\n\n:::info Java The Java Memory Model (JMM) was formally specified in JSR-133 (Java 5). It defines happens-before precisely and guarantees that correctly synchronized programs behave as if executed in some sequential order (sequential consistency for data-race-free programs). The JMM also specifies guarantees for unsynchronized access, though with fewer guarantees. :::\n\n:::info C++ C++11 introduced a formal memory model with similar concepts. Instead of \"happens-before,\" C++ uses \"synchronizes-with\" and \"happens-before.\" The key difference: C++ gives you explicit control over memory ordering via `std::memory_order`, allowing weaker (faster) guarantees when appropriate. :::\n\n:::warning Python Python has no formal memory model. CPython's GIL creates implicit synchronization, but this is an implementation detail. The `threading.Lock` provides happens-before-like guarantees (lock release to subsequent acquire), but this isn't formally specified. Portable Python code should use explicit synchronization. :::\n\n:::note C# C# provides memory model guarantees through the ECMA-335 CLI specification. The `volatile` keyword establishes acquire-release semantics. `lock` statements provide full memory barriers on entry and exit. The `Volatile.Read()` and `Volatile.Write()` methods provide explicit acquire and release semantics respectively. `Thread.MemoryBarrier()` provides a full fence. Unlike Java, C# also offers `Interlocked` methods which combine atomicity with appropriate memory barriers. :::\n\n:::note Go Go has a formal memory model documented at https://go.dev/ref/mem. It defines happens-before precisely for several synchronization primitives:\n\n- **Goroutine creation:** The `go` statement that starts a goroutine happens-before the goroutine's execution begins\n- **Channel operations:** A send on a channel happens-before the corresponding receive completes. A receive from an unbuffered channel happens-before the send completes. The closing of a channel happens-before a receive that returns zero because the channel is closed.\n- **sync.Mutex:** For any `sync.Mutex` m, the n-th call to `m.Unlock()` happens-before the (n+1)-th call to `m.Lock()` returns\n- **sync.RWMutex:** Similar rules for read-write locks\n- **sync.Once:** A single call of `f()` from `once.Do(f)` happens-before any call of `once.Do(f)` returns\n- **sync.WaitGroup:** A call to `Done()` happens-before any `Wait()` call that it unblocks returns\n- **Atomic operations:** Atomic operations in `sync/atomic` provide sequential consistency\n\nGo intentionally has a simpler memory model than C++, it does not expose relaxed or acquire-release orderings to user code. All atomic operations provide sequential consistency. :::\n\n\n| Aspect | Java | C++ | Python |\n|--------|------|-----|--------|\n| Formal model | JMM (JSR-133) | C++11 memory model | None |\n| Happens-before specified | Yes, precisely | Yes, with ordering options | Informally via locks |\n| Volatile semantics | Happens-before | No threading semantics | N/A |\n| Default atomic ordering | Sequential consistency | Sequential consistency | N/A (use locks) |\n| Weaker orderings | Not exposed | `memory_order_acquire/release/relaxed` | N/A |\n\n\n### C++ Memory Orders and Happens-Before\n\nIn C++, you can choose different levels of happens-before guarantees:\n\n\n```cpp\n#include \n\nstd::atomic x{0};\nstd::atomic ready{false};\n\n// Strongest: Sequential consistency (default)\nx.store(42); // seq_cst\nready.store(true); // seq_cst\n\n// Still creates happens-before: Acquire-Release\nx.store(42, std::memory_order_relaxed); // Just atomic, no ordering\nready.store(true, std::memory_order_release); // Release barrier\n\n// Consumer\nif (ready.load(std::memory_order_acquire)) { // Acquire barrier\n int val = x.load(std::memory_order_relaxed); // Sees 42\n}\n```\n\n\nThe release-acquire pair creates a synchronizes-with edge (similar to happens-before), but allows more compiler optimization than sequential consistency.\n\n---\n\n## Common Happens-Before Patterns\n\n### Pattern 1: The Initialization Guard\n\nEnsuring an object is fully constructed before being visible.\n\n\n```mermaid\nflowchart TB\n subgraph Thread1[\"Initializing Thread\"]\n I1[\"new Object()\"]\n I2[\"object.field1 = value1\"]\n I3[\"object.field2 = value2\"]\n I4[\"volatile ref = object\"]\n I1 --> I2 --> I3 --> I4\n end\n\n subgraph Thread2[\"Reading Thread\"]\n R1[\"Object o = ref\"]\n R2[\"use o.field1\"]\n R3[\"use o.field2\"]\n R1 --> R2 --> R3\n end\n\n I4 -.->|\"happens-before
(volatile)\"| R1\n\n style I4 fill:#69db7c,stroke:#000,color:#000\n style R1 fill:#69db7c,stroke:#000,color:#000\n```\n\n\n### Pattern 2: Signaling with volatile\n\nUsing a volatile variable as a synchronization point.\n\n\n```java\n// Configuration update pattern\nprivate volatile int configVersion = 0;\nprivate Map config = new HashMap<>();\n\n// Writer\nvoid updateConfig(Map newConfig) {\n config = new HashMap<>(newConfig); // Non-volatile write\n configVersion++; // Volatile write - publishes config\n}\n\n// Reader\nMap readConfig() {\n int version = configVersion; // Volatile read - synchronizes\n return new HashMap<>(config); // Sees config from that version\n}\n```\n\n\n### Pattern 3: The Double-Checked Locking\n\nA classic pattern that requires happens-before understanding.\n\n \n\n\n```java\npublic class Singleton {\n private static volatile Singleton instance; // MUST be volatile\n\n public static Singleton getInstance() {\n Singleton local = instance; // volatile read\n if (local == null) {\n synchronized (Singleton.class) {\n local = instance;\n if (local == null) {\n local = new Singleton();\n instance = local; // volatile write\n }\n }\n }\n return local;\n }\n}\n```\n\n\n**Why volatile is Required:**\n\nWithout volatile, this happens-before chain might not exist:\n\n1. `new Singleton()` involves multiple writes (allocate, set fields, set vtable)\n2. `instance = local` might be reordered before those writes complete\n3. Another thread could see non-null `instance` but incomplete object\n\nWith volatile:\n\n1. All writes before `instance = local` (volatile write) happen-before\n2. Any read of `instance` (volatile read) that sees non-null\n3. Transitively, the reader sees the fully constructed object\n\n \n\n---\n\n## Common Mistakes\n\n### Mistake 1: Assuming Timing Equals Ordering\n\n\n```java\n// WRONG: \"Thread 1 runs first, so Thread 2 sees the write\"\n// Thread 1 (started first)\nsharedData = 42;\n\n// Thread 2 (started second)\nint x = sharedData; // Might not see 42!\n```\n\n\n**Why it's wrong:** Being started first doesn't create happens-before. Without explicit synchronization, there's no ordering guarantee.\n\n**Fix:**\n\n\n```java\n// Use volatile\nprivate volatile int sharedData;\n\n// Or use thread join, lock, etc.\n```\n\n\n### Mistake 2: Forgetting Transitivity Works Both Directions\n\n\n```java\n// Thread 1\nx = 1; // A\nsynchronized (lock) { // B: lock\n y = 2; // C\n} // D: unlock\n\n// Thread 2\nsynchronized (lock) { // E: lock\n int readY = y; // F: sees 2\n} // G: unlock\nint readX = x; // H: Does NOT see 1!\n```\n\n\n**Why it's wrong:** The happens-before chain goes A → B → C → D → E → F → G. But H is after G, not connected to A. The chain doesn't extend past the synchronized block.\n\n**Fix:**\n\n\n```java\n// Read x inside the synchronized block\nsynchronized (lock) {\n int readY = y;\n int readX = x; // Now part of the chain\n}\n```\n\n\n### Mistake 3: Different Lock Instances\n\n\n```java\n// WRONG: Different lock objects\npublic void writer() {\n synchronized (new Object()) { // Lock A\n sharedData = 42;\n }\n}\n\npublic void reader() {\n synchronized (new Object()) { // Lock B (different!)\n int x = sharedData; // No happens-before with writer!\n }\n}\n```\n\n\n**Why it's wrong:** The monitor rule says \"unlock(m) hb lock(m)\" - the same monitor. Different objects mean no happens-before edge.\n\n**Fix:**\n\n\n```java\nprivate final Object lock = new Object(); // Shared lock\n\npublic void writer() {\n synchronized (lock) {\n sharedData = 42;\n }\n}\n\npublic void reader() {\n synchronized (lock) {\n int x = sharedData; // Now sees 42\n }\n}\n```\n\n\n---\n\n## Performance Considerations\n\nHappens-before edges aren't free. Each synchronization mechanism has different costs.\n\n### Cost Comparison\n\n\n| Mechanism | Cost | Happens-Before Strength |\n|-----------|------|------------------------|\n| Volatile read | ~1-5 ns | Single variable |\n| Volatile write | ~20-50 ns | Flushes store buffer |\n| synchronized (uncontended) | ~10-50 ns | All prior writes |\n| synchronized (contended) | ~1-10 μs | All prior writes |\n| Thread.join() | ~1-10 μs | All writes in thread |\n\n\n### Minimizing Synchronization\n\n**1. Batching:** Reduce the number of volatile writes or lock acquisitions.\n\n\n```java\n// Slow: Many volatile writes\nfor (int i = 0; i < 1000; i++) {\n volatileCounter++; // 1000 memory barriers\n}\n\n// Fast: Batch then publish\nint local = 0;\nfor (int i = 0; i < 1000; i++) {\n local++;\n}\nvolatileCounter = local; // 1 memory barrier\n```\n\n\n**2. Coarse vs Fine Granularity:** Lock less frequently, but for larger scopes.\n\n\n```java\n// Many lock acquisitions\nvoid process(List items) {\n for (Item item : items) {\n synchronized (lock) {\n process(item);\n }\n }\n}\n\n// Fewer acquisitions\nvoid process(List items) {\n synchronized (lock) {\n for (Item item : items) {\n process(item);\n }\n }\n}\n```\n\n\n**3. Read-mostly patterns:** Use volatile for reading, locks only for writing.\n\n\n```java\nprivate volatile Config config; // Readers use volatile read\n\npublic Config getConfig() {\n return config; // Fast volatile read\n}\n\npublic void updateConfig(Config newConfig) {\n synchronized (updateLock) {\n // Complex update logic\n config = newConfig; // Volatile write at the end\n }\n}\n```\n\n\n---\n\n## Interview Insights\n\n:::tip Interview Question **Q: What is a happens-before relationship?**\n\nHappens-before is a formal ordering relationship between actions in a concurrent program. If action A happens-before action B, then all memory effects of A are guaranteed to be visible when B executes. This is the foundation for reasoning about thread safety: if you can trace a happens-before chain from a write to a read, the read will see the write. :::\n\n:::tip Interview Question **Q: How does volatile create happens-before?**\n\nA volatile write happens-before any subsequent volatile read of the same variable. The key is \"subsequent\": another thread must read the volatile after the write for the edge to exist. This edge, combined with program order, means all writes before the volatile write become visible to all reads after the volatile read. :::\n\n:::tip Follow-up Questions Interviewers often follow up with:\n\n- Why does double-checked locking need volatile?\n- Can you have a happens-before without synchronization?\n- What's the difference between happens-before and wall-clock ordering?\n\n:::\n\n---\n\n## Interview Questions and Answers\n\n**Q1: What is the happens-before relationship and why is it important?**\n\nThe happens-before relationship is a partial ordering defined by the language memory model that determines when one action's effects are guaranteed to be visible to another action. It's not about wall-clock time but about guaranteed visibility.\n\nImportance:\n\n1. **Defines correctness:** A program is correctly synchronized if all shared variable accesses are ordered by happens-before\n2. **Enables reasoning:** You can prove thread safety by tracing happens-before chains\n3. **Language-defined:** The rules are precise, not dependent on hardware timing\n\nExample: In Java, `unlock(monitor)` happens-before subsequent `lock(monitor)`. This means a synchronized block's writes are visible to code that later enters the same synchronized block. Without this guarantee, we couldn't safely share data between threads.\n\n---\n\n**Q2: What are the main happens-before rules in Java?**\n\nThe Java Memory Model defines these primary happens-before rules:\n\n1. **Program order:** Each action in a thread happens-before every subsequent action in that thread.\n\n1. **Monitor lock:** An unlock on a monitor happens-before every subsequent lock on the same monitor.\n\n1. **Volatile:** A write to a volatile field happens-before every subsequent read of that field.\n\n1. **Thread start:** `Thread.start()` happens-before any action in the started thread.\n\n1. **Thread join:** All actions in a thread happen-before the `join()` call returns.\n\n1. **Thread interrupt:** `interrupt()` happens-before the interrupted thread detects the interrupt.\n\n1. **Transitivity:** If A hb B and B hb C, then A hb C.\n\nThese rules combine: you trace chains across synchronization points using transitivity to determine what a read might see.\n\n---\n\n**Q3: Why can't we rely on wall-clock time for ordering in concurrent programs?**\n\nWall-clock time is insufficient for several reasons:\n\n1. **CPU caches:** A write may complete in wall-clock time but remain invisible in a local cache, not propagated to other cores.\n\n1. **Store buffers:** Even if a write has \"happened\" by the clock, it may be buffered and not yet visible.\n\n1. **Instruction reordering:** Compilers and CPUs reorder instructions. Code that appears to run in a certain order may execute differently.\n\n1. **No global clock:** Different cores don't share a single consistent clock. \"Thread 1 wrote at time T\" doesn't mean Thread 2 sees it at time T+1.\n\n1. **Happens-before is logical:** It's defined by synchronization operations, not physical time. A volatile write \"happens-before\" a subsequent volatile read because of the memory model's guarantee, regardless of actual timing.\n\nThis is why concurrent programming requires explicit synchronization rather than timing assumptions.\n\n---\n\n**Q4: Explain how transitivity of happens-before enables the publication idiom.**\n\nThe publication idiom safely exposes an object from one thread to others. It relies on transitivity:\n\n\n```java\nprivate volatile Object published;\n\n// Writer thread\nvoid publish(Data data) {\n data.field1 = value1; // A: Write to data\n data.field2 = value2; // B: Write to data\n published = data; // C: Volatile write\n}\n\n// Reader thread\nvoid read() {\n Object d = published; // D: Volatile read\n if (d != null) {\n use(d.field1); // E: Read from data\n }\n}\n```\n\n\nThe happens-before chain:\n\n- A hb B hb C (program order in writer)\n- C hb D (volatile write-read)\n- D hb E (program order in reader)\n- By transitivity: A hb E\n\nThis means the reader is guaranteed to see the writes to `field1` and `field2`, even though those fields aren't volatile. The volatile variable acts as a \"publication barrier.\"\n\n---\n\n**Q5: How do happens-before rules differ between Java and C++?**\n\nWhile both have similar concepts, there are key differences:\n\n**Java:**\n\n- `volatile` provides happens-before between write and read\n- `synchronized` provides happens-before (unlock to lock)\n- Sequential consistency is the only memory ordering for atomics\n- Simple model: use volatile or synchronized, correctness guaranteed\n\n**C++:**\n\n- `volatile` provides NO threading guarantees\n- `std::atomic` provides atomic operations with configurable ordering\n- Multiple memory orders: `relaxed`, `acquire`, `release`, `acq_rel`, `seq_cst`\n- More complex: must choose appropriate ordering for each operation\n\nC++ example of acquire-release (similar to Java volatile):\n\n\n```cpp\n// Writer\ndata = 42;\nready.store(true, std::memory_order_release);\n\n// Reader\nif (ready.load(std::memory_order_acquire)) {\n use(data); // Sees 42\n}\n```\n\n\nThe `release` on store and `acquire` on load create a synchronizes-with edge (similar to happens-before). C++ allows weaker orderings for performance, at the cost of complexity.\n\n---\n\n## Summary\n\n### Key Takeaways\n\n- Happens-before is a logical ordering, not temporal; it defines visibility guarantees\n- Without happens-before, writes may not be visible to other threads\n- Key rules: program order, monitor lock, volatile, thread start, thread join, transitivity\n- Trace happens-before chains to prove code correctness\n- Different lock instances provide no happens-before between threads\n\n### Happens-Before Quick Reference\n\n\n| Source Action | Target Action | Rule |\n|---------------|---------------|------|\n| Earlier in same thread | Later in same thread | Program order |\n| `unlock(m)` | `lock(m)` on same m | Monitor lock |\n| `volatile` write | `volatile` read of same var | Volatile |\n| `start()` | First action in thread | Thread start |\n| Last action in thread | `join()` return | Thread join |\n| A hb B, B hb C | A hb C | Transitivity |\n\n\n### What's Next\n\nNow that you understand when visibility is guaranteed through happens-before, the next chapter explores **memory ordering**, which gives you control over exactly what reorderings are permitted. This is where you'll learn about sequential consistency, acquire-release semantics, and relaxed ordering, concepts that let you optimize for performance while maintaining correctness.\n\n---\n\n## References\n\n- JSR-133 FAQ - https://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html - Definitive happens-before explanation\n- Java Language Specification Chapter 17 - https://docs.oracle.com/javase/specs/jls/se17/html/jls-17.html - Formal JMM specification\n- \"Java Concurrency in Practice\" by Brian Goetz, Chapter 16 - The Java Memory Model explained\n- cppreference memory order - https://en.cppreference.com/w/cpp/atomic/memory_order - C++ happens-before and synchronizes-with\n- \"C++ Concurrency in Action\" by Anthony Williams, Chapter 5 - Memory ordering in C++","pageType":"concurrency-interview"}

Happens-Before Relationship

Ashish Pratap Singh

Get Premium