Re: pg_atomic_compare_exchange_*() and memory barriers
От | Andres Freund |
---|---|
Тема | Re: pg_atomic_compare_exchange_*() and memory barriers |
Дата | |
Msg-id | vhimanxfy2h5hlfxeaoxqak4bfdovy35tbrd7o2jq6q5e27mc6@6ntlvt2n3ltk обсуждение исходный текст |
Ответ на | Re: pg_atomic_compare_exchange_*() and memory barriers (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: pg_atomic_compare_exchange_*() and memory barriers
|
Список | pgsql-hackers |
Hi, 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. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: