On Mon, Nov 15, 2010 at 8:45 AM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
>> It's not a question of code rearrangement.
>
> Rearrangement of code, rearrangement of CPU instructions, or rearrangement
> of the order the changes in the memory become visible to other processes.
> The end result is the same.
I'll let Tom speak to this, because he understands it better than I
do, but I don't think this is really true. Rearrangement of code is
something that the compiler has control over, and volatile addresses
that issue by preventing the compiler from making certain assumptions,
but the order in which memory operations become visible is a result of
the architecture of the memory bus, and the compiler doesn't directly
do anything about that. It won't for example emit a cmpxchg
instruction rather than a simple store just because you declared the
variable volatile.
>> Suppose at time zero, the
>> latch is unset, but owned. At approximately the same time, SetLatch()
>> is called in one process and WaitLatch() in another process.
>> SetLatch() sees that the latch is not set and sends SIGUSR1 to the
>> other process. The other process receives the signal but, since
>> waiting is not yet set, it ignores the signal. It then drains the
>> self-pipe and examines latch->is_set. But as it turns out, the update
>> by the process which called SetLatch() isn't yet visible to this
>> process, because this process has a copy of those bytes in some
>> internal cache that isn't guaranteed to be fully coherent. So even
>> though SetLatch() already changed latch->is_set to true, it still
>> looks false here. Therefore, we go to sleep on the latch.
>
> Surely marking the latch pointer volatile would force the store to is_set to
> be flushed, if not immediately, at least before the kill() system call. No?
I don't think so.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company