21–30 of 47 posts
If 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.
Have you ever heard of "CMPXCHG8B"?
Right?
> Even that isn’t guaranteed. If you don’t say “atomic”, the compiler might decide to split up a store to optimize for speed or code size! This isn’t hypothetical; Greg Parker ran into this with libobjc. Maybe I'm tired and lack imagination, but please enlighten me. How can splitting up a store speed something up or reduce the code size? Assuming it is aligned and on a 32bit native CPU.
The linked thread doesn't say exactly how, but I can construct some way in my head: Final 32-bit store effectively stores two 16-bit values or'ed together as high-16 and low-16. You can get this without any shifting and simple addition and the proper values. If these two sixteen bit values are calculated along two very different paths which have different lengths, the compiler might opt to spill one of them early, on…
Also, 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.
I assume Rust concurrency guarantees will prevent races and have this covered. Except of course if you use unsafe. Right?
> Even that isn’t guaranteed. If you don’t say “atomic”, the compiler might decide to split up a store to optimize for speed or code size! This isn’t hypothetical; Greg Parker ran into this with libobjc. Maybe I'm tired and lack imagination, but please enlighten me. How can splitting up a store speed something up or reduce the code size? Assuming it is aligned and on a 32bit native CPU.
Maybe it chose this optimization due to register pressure, and not wanting to spill values that were still going to be used?
Also, 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.
Alpha?
I think it was something about how L1 wouldn't flush down to the inclusive L2 until commanded to, so external reads hit the stale L2.
Alpha being a pain here would be on brand, but I think this was a different arch.
The 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.
This is why it is important to tell the language what you mean. Even in C non-atomic access don't have these guarantees. It may seem pointless because in 99% of cases that "non-atomic" store compiles to the exact same instructions as a relaxed store. But that is just because you are getting lucky. The language doesn't guarantee that and with the atomic store the compiler is well within its right to emit something different (like two stores, spilling dirty values, ...).