Re: unconstify equivalent for volatile

Hi,

On February 19, 2019 7:00:58 AM PST, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
>On 2019-02-18 21:25, Andres Freund wrote:
>> ISTM this one should rather be solved by removing all volatiles from
>> latch.[ch]. As that's a cross-process concern we can't rely on it
>> anyway (and have placed barriers a few years back to allay concerns /
>> bugs due to reordering).
>
>Aren't the volatiles there so that Latch variables can be set from
>signal handlers?

Why would they be required, given we have an explicit compiler & memory barrier? That forces the compiler to spill the writes to memory already, even in a signal handler. And conversely the reading side is similarly forced - if not we have a bug in multi core systems - to read the variable from memory after a barrier.

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. Without using explicit care the variable's value can be "cached"in a register, and a change not noticed. But as volatiles aren't sufficient for cross process safety, latches need more anyway.

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