On Mon, Nov 15, 2010 at 9:51 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> writes: >>>> Hmm, SetLatch only sets one flag, so I don't see how it could malfunction >>>> all by itself. And I would've thought that declaring the Latch variable >>>> "volatile" prevents rearrangements. >>> >>> It's not a question of code rearrangement. > > Precisely. "volatile" prevents the compiler from rearranging the > instruction sequence in a way that would *issue* stores out-of-order. > However, that doesn't prevent the hardware from *executing* the stores > out-of-order from the point of view of a different processor. As Robert > noted, the risk cases here come from caching; in particular, that a > dirty cache line might get flushed to main memory later than some other > dirty cache line. There are some architectures that guarantee that this > won't happen (no doubt at significant expenditure of gates).
And in fact if this (interesting!) video is any indication, that problem is only going to get worse as core counts go up. This guy built a lock-free, wait-free hash table implementation that can run on a system with hundreds of cores. I'm just guessing here, but I strongly suspect that keeping memory in full sync across that many processors would just kill performance, so they shrug their shoulders and don't. The application programmer gets to pick up the pieces. http://video.google.com/videoplay?docid=2139967204534450862# -- 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