Re: condition variables - Mailing list pgsql-hackers

From Robert Haas
Subject Re: condition variables
Date
Msg-id CA+TgmoYLe+-xCdmMoKFeA=fHRWZJrooSXWKZojva0W30QWMDmQ@mail.gmail.com
Whole thread Raw
In response to Re: condition variables  (Thomas Munro <thomas.munro@enterprisedb.com>)
List pgsql-hackers
On Mon, Nov 21, 2016 at 11:48 PM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> Here's a version that works that way, though it allows you to call
> ConditionVariablePrepareToSleep *optionally* before you enter your
> loop, in case you expect to have to wait and would rather avoid the
> extra loop.  Maybe there isn't much point in exposing that though,
> since your condition test should be fast and waiting is the slow path,
> but we don't really really know what your condition test is.  I
> thought about that because my use case (barrier.c) does in fact expect
> to hit the wait case more often than not.  If that seems pointless
> then perhaps ConditionVariablePrepareToSleep should become static and
> implicit.  This version does attempt to suppress spurious returns, a
> bit, using proclist_contains.  No more cvSleeping.

This version looks good to me and I have committed it after doing a
bit more work on the comments.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: amcheck (B-Tree integrity checking tool)
Next
From: Robert Haas
Date:
Subject: Re: [RFC] Should we fix postmaster to avoid slow shutdown?