On Mon, Jul 03, 2023 at 03:20:31PM -0400, Olivier Dion wrote: > Hi all, > > This is a request for comments on extending the atomic builtins API to > help avoiding redundant memory barriers. Indeed, there are What atomic builtins API are you talking about? The kernel's? That's what it sounded like when I first read this sentence -- why else post your message on a kernel mailing list? > discrepancies between the Linux kernel consistency memory model (LKMM) > and the C11/C++11 memory consistency model [0]. For example, Indeed. The kernel's usage of C differs from the standard in several respects, and there's no particular reason for its memory model to match the standard's. > fully-ordered atomic operations like xchg and cmpxchg success in LKMM > have implicit memory barriers before/after the operations [1-2], while > atomic operations using the __ATOMIC_SEQ_CST memory order in C11/C++11 > do not have any ordering guarantees of an atomic thread fence > __ATOMIC_SEQ_CST with respect to other non-SEQ_CST operations [3]. After reading what you wrote below, I realized that the API you're thinking of modifying is the one used by liburcu for user programs. It's a shame you didn't mention this in either the subject line or the first few paragraphs of the email; that would have made understanding the message a little easier. In any case, your proposal seems reasonable to me at first glance, with two possible exceptions: 1. I can see why you have special fences for before/after load, store, and rmw operations. But why clear? In what way is clearing an atomic variable different from storing a 0 in it? 2. You don't have a special fence for use after initializing an atomic. This operation can be treated specially, because at the point where an atomic is initialized, it generally has not yet been made visible to any other threads. Therefore the fence which would normally appear after a store (or clear) generally need not appear after an initialization, and you might want to add a special API to force the generation of such a fence. Alan Stern
