Threads, Mutexes, and Atomics: Start with What Can Go Wrong
Comments on “Threads, Mutexes, and Atomics: Start with What Can Go Wrong”
Claim-checked. Scored by all three judges, and its checkable claims were compared with the sources it cites. How far stories are checked
Ted Koomen's Critical Section post opens a series on thread synchronization in C++20, working from what the language guarantees to what the OS and CPU do. It shows that an unsynchronized counter is a data race and therefore undefined behavior, then covers mutexes, relaxed atomics, acquire/release publication, compare-and-swap loops and the ABA problem, with a versioned-state fix. Its claims about the uncontended Linux mutex path and x86 instruction choices cite no sources. The follow-up part promises measurements; this one has none.
Why it ranked
No. 11 of 59 with a score of 0.64. The panel rated it highest on technical depth (0.92) and new information (0.84), lowest on significance (0.48). Placed No. 11, No. 18 by score alone: the placement terms moved other stories past it.
- AI judgeJudge 2claude-haiku-5-5
- Solid, accurate tutorial on threads, mutexes, atomics and memory ordering in C++20 with runnable examples; core programming material, though not a news item and mostly introductory for practitioners.
- AI judgeJudge 3gpt-5.6-luna
- A technically substantial C++ concurrency tutorial with runnable examples, memory-model explanations, Linux and CPU details, and practical correctness guidance. It is broad and useful, though introductory and not a landmark or original measurement.
Each judge wrote its line after answering the rubric, with the site and the author still hidden. Every answer behind this is in the table under Score.
Score
0.64total under rubric v2.3
- Significance0.48
- Reader interest0.67
- Audience breadth0.63
- Practical relevance0.73
- Substantiated0.77
- Technical depth0.92
- New information0.84
- Counts against: Promotional0.02
- Counts against: Overclaim0.13
Each judge’s answer per question (0–1), their mean and spread, and what the question adds to the score (weight × mean).
| Question | Judge 1 | Judge 2 | Judge 3 | Mean | Spread | Weight | Contribution (weight times mean) |
|---|---|---|---|---|---|---|---|
| SignificanceHow much does this change what people in tech know or can do? | 0.58 | 0.30 | 0.55 | 0.48 | 0.28 | +0.24 | +0.114 |
| Reader interestWould a well-informed senior engineer or tech founder want to read this today, and likely pass it on? | 0.65 | 0.55 | 0.82 | 0.67 | 0.27 | +0.26 | +0.175 |
| Audience breadthHow many people who build technology does it concern? | 0.72 | 0.50 | 0.68 | 0.63 | 0.22 | +0.13 | +0.082 |
| Practical relevanceHow useful is it to someone who builds software or tech products? | 0.80 | 0.60 | 0.78 | 0.73 | 0.20 | +0.22 | +0.160 |
| SubstantiatedHow well is it backed? Consider whether it is the primary source, and whether its main claims come with data, code, a demo, a reproducible method or citations. | 0.86 | 0.60 | 0.86 | 0.77 | 0.26 | +0.05 | +0.039 |
| Technical depthHow technically substantive is it? | 1.00 | 0.85 | 0.90 | 0.92 | 0.15 | +0.05 | +0.046 |
| New informationDoes it contain information absent from the stories covered in the last 7 days (list provided)? | 0.90 | 0.90 | 0.72 | 0.84 | 0.18 | +0.05 | +0.042 |
| PromotionalIs it mainly marketing with little substance (a press release, ad or sponsored post with no real information)? A launch post that carries real news is not promotional. | 0.03 | 0.03 | 0.01 | 0.02 | 0.02 | −0.19 | −0.004 |
| OverclaimDo the headline or conclusions claim more than the body supports? | 0.11 | 0.15 | 0.12 | 0.13 | 0.04 | −0.11 | −0.014 |
| Sum of contributions | +0.640 | ||||||
| Claim-check penalty | 0.000 | ||||||
| Total, as published | 0.640 | ||||||
Spread is the highest minus the lowest judge answer. marks a spread above 0.40: the judges disagree, and the story is marked contested.
The badge for this ranking, for the author's page or anyone's: one line of HTML, and it links back here.
<a href="https://rubric.hrih.si/editions/2026-11-01/11/"><img src="https://rubric.hrih.si/badge/2026-11-01/11.svg" alt="Ranked #11 on Rubric, 1 Nov 2026" width="238" height="28"></a>Claim check
Claim check: 5 matches source · 2 no source given · 1 couldn’t check. Each claim is compared with the source the article itself cites; a flag is published only when both checkers agree.
Matches sourceVersion
Linux clone() flags let the caller choose which resources a new task shares: CLONE_VM shares the address space, CLONE_FILES the file-descriptor table, and CLONE_THREAD places the task in the same thread group.
The cited source says the same thing.
The article says “CLONE_VM shares the address space, CLONE_FILES shares the file-descriptor table, and CLONE_THREAD places the new task in the same thread group”
The source says “If CLONE_VM is set, the calling process and the child process run in the same memory space”
Source cited by the article: man7.org/linux/man-pages/man2/clone.2.html
Matches sourceCausal conclusion
Under C++, conflicting non-atomic accesses with no happens-before relationship are a data race, and a data race is undefined behavior.
The cited source says the same thing.
The article says “These are conflicting non-atomic accesses with no happens-before relationship between them. That is a data race, and a C++ data race is undefined behavior”
The source says “The execution of a program contains a data race if it contains two potentially concurrent conflicting actions, at least one of which is not atomic, and neither happens before the…”
Source cited by the article: eel.is/c++draft/intro.races
Matches sourceGeneralization
With std::mutex, locking a mutex the thread already owns violates the locking precondition and is undefined behavior; a self-deadlock is common but not guaranteed.
The cited source says the same thing.
The article says “With std::mutex, that violates the locking precondition and gives you undefined behavior”
The source says “Preconditions: If m is of type mutex, timed_mutex, shared_mutex, or shared_timed_mutex, the calling thread does not own the mutex”
Source cited by the article: eel.is/c++draft/thread.mutex.requirements
No source givenGeneralization
On Linux, an ordinary mutex's uncontended lock path happens in user space using atomic operations, without the kernel running on every attempt.
The article gives no link or citation for it.
The article says “For a typical ordinary mutex on Linux, the uncontended path happens in user space”
The source says No source to compare with.
Matches sourceCausal conclusion
Common Linux mutex implementations use a futex to let the kernel park a waiter and wake it, and the futex wait checks the expected value as part of blocking to avoid a lost wakeup.
The cited source says the same thing.
The article says “The futex wait checks the expected value as part of blocking, which is important for avoiding a lost wakeup between checking the lock and going to sleep”
The source says “the kernel will block only if the futex word has the value that the calling thread supplied (as one of the arguments of the futex() call) as the expected value…”
Source cited by the article: man7.org/linux/man-pages/man2/futex.2.html
Couldn’t checkGeneralization
std::mutex does not promise FIFO acquisition.
The source was unreachable, paywalled or too long, or the two checkers disagreed.
The article says “std::mutex does not promise FIFO acquisition”
The source says No passage could be compared.
Source cited by the article: eel.is/c++draft/thread.mutex.requirements
Matches sourceCausal conclusion
When an acquire load reads the true written by a release store, that store synchronizes with the load, so the write to payload happens before the read of payload.
The cited source says the same thing.
The article says “When the acquire load reads the true written by the release store, that store synchronizes with the load”
The source says “An atomic operation A that performs a release operation on an atomic object M synchronizes with an atomic operation B that performs an acquire operation on M and takes its…”
Source cited by the article: eel.is/c++draft/atomics.order
No source givenVersion
On x86, a fetch-add can use LOCK XADD (or LOCK ADD if the previous value is unused), and compare-and-swap commonly uses LOCK CMPXCHG.
The article gives no link or citation for it.
The article says “On x86, a fetch-add can use LOCK XADD; if the previous value is unused, the compiler may choose a different instruction such as LOCK ADD”
The source says No source to compare with.
Also covered by
No other coverage was clustered with this story.
Elsewhere
Elsewhere: HN 2 pts, not on front page
Recorded for context only, checked 1 Nov 2026, 05:47 UTC. It played no part in the ranking.