Re: pg_atomic_compare_exchange_*() and memory barriers
От | Andres Freund |
---|---|
Тема | Re: pg_atomic_compare_exchange_*() and memory barriers |
Дата | |
Msg-id | tsznvs62vmho3qlswushbfy35gzkcyrv6bxk67g2pfbjpruepj@3ts2xiafyxxb обсуждение исходный текст |
Ответ на | Re: pg_atomic_compare_exchange_*() and memory barriers (Pavel Borisov <pashkin.elfe@gmail.com>) |
Список | pgsql-hackers |
Hi, On 2025-03-07 21:08:34 +0400, Pavel Borisov wrote: > On Fri, 7 Mar 2025 at 20:40, Alexander Korotkov <aekorotkov@gmail.com> wrote: > > Yes, there surely should be a memory barrier on another side. But > > does __ATOMIC_SEQ_CST works as a barrier for the regular read/write > > operations on the same side? > According to a reference posted by Andres [1]: > "Within a thread of execution, accesses (reads and writes) through > volatile lvalues cannot be reordered past observable side-effects > (including other volatile accesses) that are separated by a sequence > point within the same thread, but this order is not guaranteed to be > observed by another thread, since volatile access does not establish > inter-thread synchronization." How is volatile relevant here? > Also: "as soon as atomic operations that are not tagged > memory_order_seq_cst enter the picture, the sequential consistency is > lost" Sequential consistency is lost, but that does *NOT* mean that acquire/release guarantees that are also guaranteed by ATOMIC_SEQ_CST are lost. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: