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

On 15.11.2010 16:51, Tom Lane wrote:
> Heikki Linnakangas<heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
>> I believe it's safe to
>> assume that two operations using a volatile pointer will not be
>> rearranged wrt. each other.
>
> This is entirely wrong, so far as cross-processor visibility of changes
> is concerned.

Ok.

In SetLatch, is it enough to add the SpinLockAcquire() call *after*
checking that is_set is not already set? Ie. still do the quick exit
without holding a lock. Or do we need a memory barrier operation before
the fetch, to ensure that we see if the other process has just cleared
the flag with ResetLatch() ? Presumable ResetLatch() needs to call
SpinLockAcquire() anyway to ensure that other processes see the clearing
of the flag.

>> Tom's other scenario, where changing some other variable in shared
>> memory might not have become visible to other processes when SetLatch()
>> runs, seems more plausible (if harder to run into in practice). But if
>> the variable is meant to be examined by other processes, then you should
>> use a lock to protect it.
>
> In that case, of what use is the latch stuff? The whole point with that
> (or at least a lot of the point) is to not have to take locks.

The use case for a latch is to wake up another process to examine other
piece of shared memory (or a file or something else), and take action
based on that other state if needed. Access to that other piece of
shared memory needs locking or some other means of concurrency control,
regardless of the mechanism used to wake up the other process.

Take the walsender latches for example. The "other piece of shared
memory" is the current WAL flush location. The latch is used to wake up
a walsender after flushing some WAL. The latch itself doesn't protect
the access to the WAL flush pointer in any way, GetFlushRecPtr() uses a
spinlock for that.

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