Latches with weak memory ordering (Re: max_wal_senders must die)

On 14.11.2010 22:55, Tom Lane wrote:
> Heikki Linnakangas<heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
>> On 13.11.2010 17:07, Tom Lane wrote:
>>> Robert Haas<robertmhaas(at)gmail(dot)com> writes:
>>>> Come to think of it, I'm not really sure I understand what protects
>>>> SetLatch() against memory ordering hazards. Is that actually safe?
>>>
>>> Hmm ... that's a good question. It certainly *looks* like it could
>>> malfunction on machines with weak memory ordering.
>
>> Can you elaborate?
>
> Weak memory ordering means that stores into shared memory initiated by
> one processor are not guaranteed to be observed to occur in the same
> sequence by another processor. This implies first that the latch code
> could malfunction all by itself, if two processes manipulate a latch at
> about the same time, and second (probably much less likely) that there
> could be a malfunction involving a process that's waited on a latch not
> seeing the shared-memory status updates that another process did "before"
> setting the latch.
>
> This is not at all hypothetical --- my first attempt at rewriting the
> sinval signaling code, a couple years back, failed on PPC machines in
> the buildfarm because of exactly this type of issue.

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.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com