Re: valgrind versus pg_atomic_init() - Mailing list pgsql-hackers

From Tom Lane
Subject Re: valgrind versus pg_atomic_init()
Date
Msg-id 1416276.1592365678@sss.pgh.pa.us
Whole thread Raw
In response to Re: valgrind versus pg_atomic_init()  (Andres Freund <andres@anarazel.de>)
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: Re: valgrind versus pg_atomic_init()
Next
From: Noah Misch
Date:
Subject: Re: valgrind versus pg_atomic_init()