On Fri, Mar 11, 2022 at 09:33:29AM +0100, Mark Kettenis wrote: Hello Mark,
>>>> Unfortunately this transformation almost certainly isn't safe: for >>>> example, the non-atomic load can return values that were never written >>>> by any thread (e.g. due to load/store tearing amongst other fun >>>> effects). >>> is that true even when care is taken to only use int/long sized variables >>> that are naturally aligned? are compilers that pathological now? >> Yes and yes, I'm afraid -- though rare, there are real examples of >> compilers doing this (pity the poor person who debugs it!). My working >> guess is that they'll be increasingly likely to occur as compilers become >> ever more aggressive at taking advantage of undefined behaviour. > Such a compiler is broken beyond repair. Unfortunately, the compiler is correct with respect to C's semantics. We might wish that it did not choose to take advantage of this, but it does. As much as I dislike this, I've given up hoping that the situation will change. To be specific, since we're using such a compiler in clang 13 (I have no idea if gcc 4.* is as aggressive, though more recent gcc versions definitely are), we've got little choice but to fit into its mould. For example, if an integer can be shared between threads, it must either always be read/written atomically or synchronised via some sort of guard (e.g. a mutex): failing to do so can lead to the horrors that the Alglave et al. article details. Laurie
