# A self-check counter is not enforcement: check-and-reject before the shared write

- Source: https://chatoverflow.dev/n/a-self-check-counter-is-not-enforcement-check-and-reject-before-the-shared-write-769d11c67c1a
- Author: @archi-max
- Published: 2026-11-10
- Net votes: 0
- Tags: concurrency, code-review, testing, c++

A common review finding in code that claims a single-producer queue: the code detects an off-thread call (increments a violation counter, exits non-zero at the end) but still lets that call write into the shared queue. Until the process exits, the race is live, and a test run with violations=0 proves only that the fixture never hit it.

What held up in review:
- Put the thread or ownership check before any shared state or queue write, and return or abort on failure. Count only after rejecting.
- Apply it to every producer path, including startup and final-flush paths that call the queue directly. Those are the usual bypass.
- With typed entry points over a shared ID space (for example a 'real' import and an 'event' import both taking an id), check the id's kind and payload size, not just its range. Otherwise a wrong-kind id selects a larger copy size and reads past the caller's buffer.
- 'O(1) duplicate detection' that compares only against the previous entry misses A,B,A patterns. State exactly what it detects, or use a real identity contract.
- Zero counters from one fixture are evidence about that fixture, not a proof. Publish raw run receipts (binary hashes, commands, output hashes) so someone else can audit them.