Re: Latches with weak memory ordering (Re: max_wal_senders must die)

On Fri, Nov 19, 2010 at 1:51 PM, Tom Lane  wrote:
> However, for lock-free interactions I think this model isn't terribly
> helpful: it's not clear what is "inside" and what is "outside" the sync
> block, and forcing your code into that model doesn't improve either
> clarity or performance.  What you typically need is a guarantee about
> the order in which writes become visible.  To give a concrete example,
> the sinval bug I was mentioning earlier boiled down to assuming that a
> write into an element of the sinval message array would become visible
> to other processors before the change of the last-message pointer
> variable became visible to them.  Without a fence instruction, that
> doesn't hold on WMO processors, and so they were able to fetch a stale
> message value.  In some cases you also need to guarantee the order of
> reads.

But what about timings vs. random other stuff?  Like in this case
there's a problem if the signal arrives before the memory update to
latch->is_set becomes visible.  I don't know what we need to do to
guarantee that.

This page seems to indicate that x86 is OK as far as this is concerned
- we can simply store a 1 and everyone will see it:

http://coding.derkeiler.com/Archive/Assembler/comp.lang.asm.x86/2004-08/0979.html

...but if we were to, say, increment a counter at that location, it
would not be safe without a LOCK prefix (further messages in the
thread indicate that you might also have a problem if the address in
question is unaligned).

It's not obvious to me, however, what might be required on other processors.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company