Compare happens-before race detection with lockset-based detection (the Eraser style, where a tool tracks which locks are consistently held): what does each report, and where does each go wrong?

## Two different questions The two families answer different questions, and that explains everything about their behaviour. - **Happens-before** asks: *in this execution, were these two conflicting accesses ordered?* It computes a relation over real events. - **Lockset** asks: *is this location consistently protected by some lock?* It checks adherence to a programming discipline. The first is a statement about an execution; the second is a statement about a policy the code appears to follow. ## How lockset works Each thread maintains the set of locks it currently holds. Each shared location gets a **candidate set** `C(x)`. On the first access, `C(x)` is initialized to the locks held. On each later access, `C(x) := C(x) ∩ locks_held`. If `C(x)` becomes empty, no lock is held on all accesses, and the tool reports. Raw, this fires constantly. The original algorithm therefore adds a small **state machine** per location to suppress the legitimate patterns: `Virgin` (never accessed) → `Exclusive` (touched by one thread only — no checking, this is thread-local) → `Shared` (read by others — read-only sharing is safe, warn only on write) → `Shared-Modified` (the state where the empty-intersection rule actually fires). Read-write locks are handled by only requiring a write lock for writes. Even with these refinements, the false-positive rate is the algorithm's defining problem. ## Where lockset false-alarms Every correct synchronization idiom that is *not* "a common mutex" looks like a violation: - **Ownership transfer**: a producer fills a buffer, hands it through a queue, and never touches it again. Two threads, one write each, no common lock — correct, reported. - **Initialization before publication**: fields written by the creating thread before the object becomes visible. - **Join-based ordering**: worker writes, parent joins and reads. - **Barriers and phases**: threads write disjoint ranges in phase 1, read others' ranges in phase 2. - **Lock-free structures** using atomic read-modify-write with explicit ordering. - **Benign-by-design patterns** such as a private object promoted to shared after a fence. A tool that cannot recognize these buries the real findings. Historically this is why pure lockset tools lost adoption: engineers stopped reading the output. ## Where happens-before misses The complementary weakness is **schedule dependence**. Consider a field guarded by a lock on the write path but read without the lock. If, in the observed run, the reading thread happens to take some *other* lock that the writer also released, or happens to start after a join, the accesses are ordered in that execution and no report appears. The code is still broken. Similarly, code that only races under a rare interleaving — the second thread arriving during a narrow window — will be silently clean for thousands of runs. Lockset would have flagged both cases on the very first execution, because it never asks whether the race happened, only whether the discipline was followed. ## The hybrid resolution The practical answer, and the one interviewers want, is that these compose. A hybrid detector: 1. Computes happens-before as the ground truth. Any pair that is unordered is reported with full confidence. 2. Additionally tracks locksets. For pairs that *were* ordered in this run but share no protecting lock, the ordering may be accidental — these become lower-confidence warnings, or candidates for the schedule-exploration stage to try to realize. 3. Uses the happens-before information to suppress lockset warnings arising from genuine ordering (joins, queue handoffs, initialization), which removes the bulk of the false positives. The result gets some of lockset's schedule-insensitivity without drowning the user. Most modern dynamic detectors sit somewhere on this spectrum, weighted heavily toward happens-before because engineering teams will not tolerate noisy tools. ## Choosing and operating The operational lesson: precision determines whether a tool survives in a team, and coverage determines whether it finds anything. A precise detector is worth enabling in CI and treating as a hard failure. A noisy one needs a triage owner and an annotation vocabulary, or it decays into a permanently-yellow build. When you pick, ask who reads the output and what happens when it fires — that decides more than the algorithm's theoretical detection power.