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
