On Mon, Nov 15, 2010 at 9:51 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Heikki Linnakangas <heikki.linnakangas@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
