On Fri, Nov 19, 2010 at 1:51 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
