Safe Lock-free Primitives with iceoryx2's ByteAtomic • Hacker News Board

Post by charleslmunger » Fri, Aug 07, 2026, 1:36 PM UTC

jimaway123 wrote: post #24

charleslmunger wrote: post #8

Earlier quoted context omitted.

From a hardware perspective this is correct. From a language perspective it's UB, and unless your compiler has defined that UB, it doesn't matter what the hardware's behavior is unless you're writing assembly.

So you're saying the problem that this article is solving is just preventing the language from generating code that can possibly load some incorrect bytes from main memory, even though these incorrect bytes will in every case be ignored? Why is this considered a problem at all?

It's a problem for language specifiers, basically. The behavior is undefined in the standard; to rely on it you either need your implementation of the standard to define it themselves, or you need to bet that there is no possible sequence of machine instructions the compiler could emit that would implement the defined behavior in a way where a data race would do something harmful.

As far as I know there is no reasonable compiler that wasn't specifically trying to add some kind of sanitizer that would emit anything other than plain memory reads, but it would be nice to not have to worry. But sanitizers are handy! I can imagine some sanitizer implementation forgoing extra internal synchronization that would only be needed in the case of program UB anyway.