On Fri, Nov 19, 2010 at 1:51 PM, Tom Lane <tgl@sss.pgh.pa.us> 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