Re: valgrind versus pg_atomic_init()

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: valgrind versus pg_atomic_init()
Дата
Msg-id 1416276.1592365678@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: valgrind versus pg_atomic_init()  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On June 16, 2020 8:24:29 PM PDT, Noah Misch <noah@leadboat.com> wrote:
>> Suppose the initializing process does:
>>
>> pg_atomic_init_u64(&somestruct->atomic, 123);
>> somestruct->atomic_ready = true;
>>
>> In released versions, any process observing atomic_ready==true will
>> observe
>> the results of the pg_atomic_init_u64().  After the commit from this
>> thread,
>> that's no longer assured.

> Why did that hold true before? There wasn't a barrier in platforms already (wherever we know what 64 bit reads/writes
havesingle copy atomicity). 

I'm confused as to why this is even an interesting discussion.  If the
timing is so tight that another process could possibly observe partially-
initialized state in shared memory, how could we have confidence that the
other process doesn't look before we've initialized the atomic variable or
spinlock at all?

I think in practice all we need depend on in this area is that fork()
provides a full memory barrier.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: valgrind versus pg_atomic_init()
Следующее
От: Noah Misch
Дата:
Сообщение: Re: valgrind versus pg_atomic_init()