Re: unconstify equivalent for volatile - Mailing list pgsql-hackers

From Andres Freund
Subject Re: unconstify equivalent for volatile
Date
Msg-id 20190219170244.dbdbkp5gtimnhql3@alap3.anarazel.de
Whole thread Raw
In response to Re: unconstify equivalent for volatile  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: unconstify equivalent for volatile  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
Hi,

On 2019-02-19 11:48:16 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > The real reason why variables commonly need to be volatile when used in
> > signal handlers is not the signal handler side, but the normal code flow
> > side.
> 
> Yeah, exactly.  You have not explained why it'd be safe to ignore that.

Because SetLatch() is careful to have a pg_memory_barrier() before
touching shared state and conversely so are ResetLatch() (and
WaitEventSetWait(), which already has no volatiles). And if we've got
this wrong they aren't safe for shared latches, because volatiles don't
enforce meaningful ordering on weakly ordered architectures.

But even if we were to decide we'd want to keep a volatile in SetLatch()
- which I think really would only serve to hide bugs - that'd not mean
it's a good idea to keep it on all the other functions in latch.c.

Greetings,

Andres Freund


pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Some thoughts on NFS
Next
From: Tom Lane
Date:
Subject: Re: speeding up planning with partitions