From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: releaseOk and LWLockWaitForVar |
Date: | 2014-06-23 16:37:50 |
Message-ID: | 53A857DE.9000900@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 06/17/2014 03:17 PM, Andres Freund wrote:
> LWLockWaitForVar() doesn't set releaseOk to true when waiting
> again. Isn't that a bug?
LWLockWaitForVar() waits in LW_WAIT_UNTIL_FREE mode, because it's not
interested in acquiring the lock, it just wants to be woken up when it's
released (or the "var" is updated). LWLockRelease doesn't clear
releaseOK when it wakes up a LW_WAIT_UNTIL_FREE-mode waiter.
> What if there's another locker coming in after
> LWLockWaitForVar() returns from the PGSemaphoreLock() but before it has
> acquire the spinlock? Now, it might be that it's unproblematic because
> of hte specific way these locks are used right now, but it doesn't seem
> like a good idea to leave it that way.
In that scenario, LWLockWaitForVar() will grab the spinlock, after the
other process. What happens next depends on the whether the value of the
variable it guards was changed. If it was, LWLockWaitForVar() will see
that it changed, and return false without waiting again. If the value
didn't change, it will sleep until the new locker releases the lock. In
either case, I don't see a problem with releaseOK. It seems correct as
it is.
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2014-06-23 16:38:17 | Re: Atomics hardware support table & supported architectures |
Previous Message | Robert Haas | 2014-06-23 16:34:32 | Re: API change advice: Passing plan invalidation info from the rewriter into the planner? |