Reproduce and Diagnose Race Condition Using Thread Sanitizer

Undefined Behavior at Scale

A data race occurs when two threads access the same memory location, at least one write is present, and no synchronization orders them. The C memory model calls this undefined behavior; observed output can change run to run.

Thread Sanitizer

Compile with -fsanitize=thread:

• TSan instruments loads/stores
• Reports stack traces for conflicting accesses
• Overhead is high; use on test builds only

For example, counter++ without atomics from two threads may report a race at the increment line even if you usually see 1000 as the final value.

Why This Matters in Production

ThreadSanitizer, the tool this task exercises, was built at Google after data races caused real, hard-to-reproduce production incidents in Chrome's multi-process renderer and is now standard in Go's -race flag and Rust's Miri. The double-checked-locking bug shown here is a famous real pattern (formalized as broken by the 'C++ and the Perils of Double-Checked Locking' paper) that misled a generation of C++ programmers into shipping racy singleton initialization.

Debugging Checklist

Before you call the implementation done, walk failure modes on purpose. Test empty structures, single-element edge cases, maximum concurrency, and errno paths that must not crash the program. OS code usually fails in production when happy-path tests pass but invariants break under contention or memory pressure.

Implementation Notes

Keep structures small and name fields after kernel counterparts when possible. That lets you read man pages and kernel source side by side while you work. Print observable events during development; remove noisy logs once tests pass reliably.

For This Exercise

You will write a deliberately racy program, run it under TSan, and apply fixes with mutexes or atomics. This exercise requires pasting the TSan report and explaining which invariant the fix restores.