From: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | robertmhaas(at)gmail(dot)com |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: condition variables |
Date: | 2016-11-22 02:05:09 |
Message-ID: | 20161122.110509.210618987.horiguchi.kyotaro@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello,
At Mon, 21 Nov 2016 15:57:47 -0500, Robert Haas <robertmhaas(at)gmail(dot)com> wrote in <CA+TgmobFjwcFEiq8j+fvH5CdXHdVJffmemNLq8MqFesg2+4Gwg(at)mail(dot)gmail(dot)com>
> On Thu, Aug 11, 2016 at 5:47 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> > So, in my
> > implementation, a condition variable wait loop looks like this:
> >
> > for (;;)
> > {
> > ConditionVariablePrepareToSleep(cv);
> > if (condition for which we are waiting is satisfied)
> > break;
> > ConditionVariableSleep();
> > }
> > ConditionVariableCancelSleep();
>
> I have what I think is a better idea. Let's get rid of
> ConditionVariablePrepareToSleep(cv) and instead tell users of this
> facility to write the loop this way:
>
> for (;;)
> {
> if (condition for which we are waiting is satisfied)
> break;
> ConditionVariableSleep(cv);
> }
> ConditionVariableCancelSleep();
It seems rather a common way to wait on a condition variable, in
shorter,
| while (condition for which we are waiting is *not* satisfied)
| ConditionVariableSleep(cv);
| ConditionVariableCancelSleep();
> ConditionVariableSleep(cv) will check whether the current process is
> already on the condition variable's waitlist. If so, it will sleep;
> if not, it will add the process and return without sleeping.
>
> It may seem odd that ConditionVariableSleep(cv) doesn't necessary
> sleep, but this design has a significant advantage: we avoid
> manipulating the wait-list altogether in the case where the condition
> is already satisfied when we enter the loop. That's more like what we
The condition check is done far faster than maintaining the
wait-list for most cases, I believe.
> already do in lwlock.c: we try to grab the lock first; if we can't, we
> add ourselves to the wait-list and retry; if we then get the lock
> after all we have to recheck whether we can get the lock and remove
> ourselves from the wait-list if so. Of course, there is some cost: if
> we do have to wait, we'll end up checking the condition twice before
> actually going to sleep. However, it's probably smart to bet that
> actually needing to sleep is fairly infrequent, just as in lwlock.c.
>
> Thoughts?
FWIW, I agree to the assumption.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2016-11-22 02:20:29 | Re: Logical decoding on standby |
Previous Message | Tom Lane | 2016-11-22 01:40:16 | Re: regression tests fails |