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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
