[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <feb9c2c0-24ce-40bf-a865-5898ffad3005@rowland.harvard.edu>
Date: Mon, 3 Jul 2023 16:27:37 -0400
From: Alan Stern <stern@...land.harvard.edu>
To: Olivier Dion <odion@...icios.com>
Cc: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, rnk@...gle.com,
Andrea Parri <parri.andrea@...il.com>,
Will Deacon <will@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Boqun Feng <boqun.feng@...il.com>,
Nicholas Piggin <npiggin@...il.com>,
David Howells <dhowells@...hat.com>,
Jade Alglave <j.alglave@....ac.uk>,
Luc Maranget <luc.maranget@...ia.fr>,
"Paul E. McKenney" <paulmck@...nel.org>,
Nathan Chancellor <nathan@...nel.org>,
Nick Desaulniers <ndesaulniers@...gle.com>,
Tom Rix <trix@...hat.com>, linux-kernel@...r.kernel.org,
linux-arch@...r.kernel.org, gcc@....gnu.org, llvm@...ts.linux.dev
Subject: Re: [RFC] Bridging the gap between the Linux Kernel Memory
Consistency Model (LKMM) and C11/C++11 atomics
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
Powered by blists - more mailing lists