On 07/29/2015 03:08 PM, Andres Freund wrote:
> On 2015-07-29 14:55:54 +0300, Heikki Linnakangas wrote:
>> On 07/29/2015 02:39 PM, Andres Freund wrote:
>>> In an earlier email you say:
>>>> After the spinlock is released above, but before the LWLockQueueSelf() call,
>>>> it's possible that another backend comes in, acquires the lock, changes the
>>>> variable's value, and releases the lock again. In 9.4, the spinlock was not
>>>> released until the process was queued.
>>>
>>> But that's not a problem. The updater in that case will have queued a
>>> wakeup for all waiters, including WaitForVar()?
>>
>> If you release the spinlock before LWLockQueueSelf(), then no. It's possible
>> that the backend you wanted to wait for updates the variable's value before
>> you've queued up. Or even releases the lock, and it gets re-acquired by
>> another backend, before you've queued up.
>
> For normal locks the equivalent problem is solved by re-checking wether
> a conflicting lock is still held after enqueuing. Why don't we do the
> same here? Doing it that way has the big advantage that we can just
> remove the spinlocks entirely on platforms with atomic 64bit
> reads/writes.
Ah, ok, that should work, as long as you also re-check the variable's
value after queueing. Want to write the patch, or should I?
- Heikki