From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
Cc: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: condition variables |
Date: | 2016-11-22 19:28:46 |
Message-ID: | CA+TgmoYLe+-xCdmMoKFeA=fHRWZJrooSXWKZojva0W30QWMDmQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Nov 21, 2016 at 11:48 PM, Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-11-22 19:35:38 | Re: [RFC] Should we fix postmaster to avoid slow shutdown? |
Previous Message | Peter Geoghegan | 2016-11-22 18:56:07 | Re: amcheck (B-Tree integrity checking tool) |