There's No Such Thing as “Implicitly Atomic”
belkadan.com
There's No Such Thing as “Implicitly Atomic”
1–10 of 47 posts
Re: There's No Such Thing as “Implicitly Atomic”
#2Also, I half remember an architecture that essentially put no upper bounds on when a normal write would be visible to other cores without a barrier.
Re: There's No Such Thing as “Implicitly Atomic”
#3Also, I half remember an architecture that essentially put no upper bounds on when a normal write would be visible to other cores without a barrier.
This is touched on in Olivier Giroux' talk on forward progress in C++[1]. I've time-stamped the section on the roach motel problem, which ends with the observation that the execution model should capture "as-if isolated for a finite time." But even if C++ were to be improved in this way, you'd still only get the guarantee if you expressed the write as an atomic. There are no guarantees for non-atomic writes and shouldn't be.
But this gets to the deeper problem of the blog. There are three ways you can reason about these kinds of problems:
1. What happens with the execution of assembly language on the chip? Behavior is pretty well specified by the ISA, and you absolutely can reason operationally. The x86 memory model includes TSO, so you get fairly strong guarantees; it's basically acquire/release "for free," so you know you won't get tearing or other such things.
2. The formal memory model provided by the language. In the case of C and C++, it's also pretty well specified, and there's lots of work that's gone into it over many years. Again, it's possible to reason productively in this world, though it's quite different than case 1 - ultimately you've got causality graphs and other things expressed on an abstract machine. Ideally you'd do this work with formal proofs, but model checkers like CDSChecker can help a lot.
3. Informal reasoning based on an intuitive model of what the computer "should" do. This is serious YOLO territory, and basically a guarantee that whatever you write will be broken, possibly leading to serious security vulnerabilities. It's popular among a subset of confidently wrong HN commenters though, who I expect will come out in force in this thread.
[1]: https://youtu.be/g9Rgu6YEuqY?si=ZvKlDnqKOqzfFVSZ&t=4267
Re: There's No Such Thing as “Implicitly Atomic”
#4The FreeBSD kernel only runs on platforms where 32-bit sized and aligned ordinary loads and stores are atomic; this is a requirement that it demands of the hardware. This may not be (extremely) portable, or may not work for Swift, or userspace under some very weird runtime environments, but it is true of the vast majority of CPU hardware out there.
Re: There's No Such Thing as “Implicitly Atomic”
#5If a language is self-hosting that means it must guarantee translation of code that is not explicitly atomic in that language to instructions which are explicitly atomic in the CPU ISA to implement language explicit atomics.
I don't feel that the article take is useful or informative and amounts to gatekeeping ISA parallelism.
Re: There's No Such Thing as “Implicitly Atomic”
#6Interestingly, the Go memory model[1] does in fact guarantee atomicity of word-sized reads/writes:
> Otherwise, each read of a single-word-sized or sub-word-sized memory location must observe a value actually written to that location (perhaps by a concurrent executing goroutine) and not yet overwritten.
However, it allows the implementation to immediately exit and report an error as well.
Re: There's No Such Thing as “Implicitly Atomic”
#7The Go runtime has quite a few places where it assumes atomic load/store behavior of int sized words as well as the eventual propagation of the stores.
I always get a little anxious when looking at such code. But it seems to work well in practice?
Re: There's No Such Thing as “Implicitly Atomic”
#8The Go runtime has quite a few places where it assumes atomic load/store behavior of int sized words as well as the eventual propagation of the stores. I always get a little anxious when looking at such code. But it seems to work well in practice?
Go's memory model is more constrained than C, C++, and Swift and this case is specifically addressed: https://go.dev/ref/mem#restrictions.
"...each read of a single-word-sized or sub-word-sized memory location must observe a value actually written to that location"
Re: There's No Such Thing as “Implicitly Atomic”
#9The FreeBSD kernel only runs on platforms where 32-bit sized and aligned ordinary loads and stores are atomic; this is a requirement that it demands of the hardware. This may not be (extremely) portable, or may not work for Swift, or userspace under some very weird runtime environments, but it is true of the vast majority of CPU hardware out there.
So FreeBSD can run only on simple single 32-bit CPUs with no cache (or no registers)? I would argue that outside of a few select embedded controllers there's almost no hardware out there that meets that requirement.
Re: There's No Such Thing as “Implicitly Atomic”
#10The FreeBSD kernel only runs on platforms where 32-bit sized and aligned ordinary loads and stores are atomic; this is a requirement that it demands of the hardware. This may not be (extremely) portable, or may not work for Swift, or userspace under some very weird runtime environments, but it is true of the vast majority of CPU hardware out there.
A problem identified in the article is that if you access a word-size object, your compiler may use a load or store of some different size, violating your assumptions about atomicity. This is not just about ISAs.
The example cited was in a library written in C.