Re: unconstify equivalent for volatile

On 2019-02-19 18:02, Andres Freund wrote:
> 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.

That makes sense.

> 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.

What is even the meaning of having a volatile Latch * argument on a
function when the actual latch variable (MyLatch) isn't volatile?  That
would just enforce certain constraints on the compiler inside that
function but not on the overall program, right?

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services