Hi, On 2025-03-08 17:06:38 +0200, Alexander Korotkov wrote: > On Sat, Mar 8, 2025 at 3:41 PM Andres Freund <and...@anarazel.de> wrote: > > > > On 2025-03-08 08:02:41 -0500, Andres Freund wrote: > > > From the C/C++ standard atomics model it doesn't make sense to say that a > > > failed CAS has release semantics, as there simply isn't a write that > > > could be > > > ordered! What their barriers guarantee is ordering between multiple > > > memory > > > operation, you can't order multiple writes if you don't have multiple > > > writes... The synchronization in the C/C++ model is only established > > > between > > > accesses of the same variable and there's no write in the case of a failed > > > CAS, so there's nothing that could establish a release-acquire ordering. > > > > > > Unfortunately that model doesn't mesh well with barriers that aren't > > > attached > > > to read/modify operations. Which is what we ended up with... > > > > Adding a full barrier to failed CAS would be a rather large overhead, > > undesirable in just about any sane algorithm. As a consequence, I think what > > we ought to do is to redefine the barrier semantics to only imply an acquire > > barrier in case CAS fails. > > Thank you, I'm good with this solution. Can I leave this on you? I'm > not feeling myself strong to word this correctly.
Not in the next ~four weeks. If you ping me afterwards, I can give it a go. FWIW, I am fairly certain that any non-toy algorithm that requires a full memory barrier instead of just an acquire in case of a CAS failure is chock full of concurrency bugs. Greetings, Andres Freund
