Re: condition variables - Mailing list pgsql-hackers
From | Kyotaro HORIGUCHI |
---|---|
Subject | Re: condition variables |
Date | |
Msg-id | 20161122.110509.210618987.horiguchi.kyotaro@lab.ntt.co.jp Whole thread Raw |
In response to | Re: condition variables (Robert Haas <robertmhaas@gmail.com>) |
Responses |
Re: condition variables
(Thomas Munro <thomas.munro@enterprisedb.com>)
|
List | pgsql-hackers |
Hello, At Mon, 21 Nov 2016 15:57:47 -0500, Robert Haas <robertmhaas@gmail.com> wrote in <CA+TgmobFjwcFEiq8j+fvH5CdXHdVJffmemNLq8MqFesg2+4Gwg@mail.gmail.com> > On Thu, Aug 11, 2016 at 5:47 PM, Robert Haas <robertmhaas@gmail.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
pgsql-hackers by date: