Re: releaseOk and LWLockWaitForVar

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

In response to

Browse pgsql-hackers by date

  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?