Re: valgrind versus pg_atomic_init()

Hi,

On June 16, 2020 8:24:29 PM PDT, Noah Misch <noah(at)leadboat(dot)com> wrote:
>On Sun, Jun 14, 2020 at 09:16:20PM -0700, Andres Freund wrote:
>> On 2020-06-14 18:55:27 -0700, Noah Misch wrote:
>> > Does something guarantee the write will be globally-visible by the
>time the
>> > first concurrent accessor shows up?
>>
>> The function comments say:
>>
>> *
>> * Has to be done before any concurrent usage..
>> *
>> * No barrier semantics.
>>
>>
>> > (If not, one could (a) do an unlocked ptr->value=0, then the atomic
>> > write, or (b) revert and improve the suppression.) I don't doubt
>it's
>> > fine for the ways PostgreSQL uses atomics today, which generally
>> > initialize an atomic before the concurrent-accessor processes even
>> > exist.
>>
>> I think it's unlikely that there are cases where you could safely
>> initialize the atomic without needing some form of synchronization
>> before it can be used. If a barrier were needed, what'd guarantee the
>> concurrent access happened after the initialization in the first
>place?
>
>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 have single copy atomicity).

Andres

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.