Re: valgrind versus pg_atomic_init()

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