64 of 64 tasks passed. ThreadSanitizer still found the race in the destructor

The defect is one byte wide. The destructor writes `stop_ = true` at pool.h line 49 with no lock held, then calls `notify_all` and joins ^[10]. Every worker reads that same flag inside the condition-variable predicate at line 22 while holding the mutex ^[11], and `enqueue` takes a `lock_guard` before its own read of it ^[12]. The flag is declared as a plain `bool` member of the class, not an atomic [c9b]. ThreadSanitizer reported a write of size 1 by the main thread and a previous read of size 1 by worker thread T2, which lines up with that single `bool` ^[15][3].

That is why the functional run looked clean. The only consumer of the write is a predicate that gets re-evaluated when a worker reacquires the mutex after the notify, so in the observed run the queue drained and all 64 futures were satisfied with a clean exit ^[1].

The test was not lazy about the shutdown path either. Four workers, 64 tasks, each sleeping 200 microseconds before incrementing an atomic counter, with the pool destroyed inside the enclosing scope ^[13]. That is roughly 3.2 milliseconds of sleeping per worker behind an enqueue loop that returns almost immediately ^[1], so the destructor arrives with most of the queue still unprocessed. The window the author was aiming at was wide open, and the test still printed "completed 64 of 64 tasks" with no warnings under `-Wall -Wextra -O2` ^[14].

So the practical question is where the sanitizer runs. Note that the two invocations differ by more than a flag: the functional build is `-O2`, the sanitizer build is `-fsanitize=thread -O1 -g` ^[14][15][2]. A ThreadSanitizer gate is a second compile of the tree with its own configuration, which is the actual cost line in CI, and it is not something you bolt onto the existing build step.

The alternative policy, run sanitizers when someone suspects a concurrency bug, fails on this evidence, because nobody suspected anything. The author writes that a reasonable engineer would ship this, and describes the generated file as close to the canonical implementation, off by exactly one lock scope ^[16][17]. Reading it does not help. The reviewer that caught the miss was mechanical.

One caveat on provenance: the case study discloses that it was prepared as part of MonkeyCode's product outreach, with the model and the sanitizer server both coming from that vendor's free tiers ^[5]. The author states the workflow does not depend on either product and that the commands run on any Linux box with clang ^[18]. The commands shown are plain clang invocations, which is the part a reader can check.