Re: Condition variable live lock
От | Thomas Munro |
---|---|
Тема | Re: Condition variable live lock |
Дата | |
Msg-id | CAEepm=1jfBU6F6aW-uvt+c698TmcwsjYhS8jC47YAvm6=kE7qQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Condition variable live lock (Thomas Munro <thomas.munro@enterprisedb.com>) |
Ответы |
Re: Condition variable live lock
|
Список | pgsql-hackers |
On Mon, Jan 8, 2018 at 5:25 PM, Thomas Munro <thomas.munro@enterprisedb.com> wrote: > On Sun, Jan 7, 2018 at 10:43 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Actually ... perhaps a better design would be to have >> ConditionVariable[PrepareTo]Sleep auto-cancel any prepared sleep for >> a different condition variable, analogously to what we just did in >> ConditionVariableBroadcast, on the same theory that whenever control >> returns to the other CV wait loop it can re-establish the relevant >> state easily enough. I have to think that if the use of CVs grows >> much, the existing restriction is going to become untenable anyway, >> so why not just get rid of it? > > +1 > > It's a more robust API this way. One very small thing after another look: - Assert(cv_sleep_target == NULL); + if (cv_sleep_target != NULL) + ConditionVariableCancelSleep(); The test for cv_sleep_target != NULL is redundant since ConditionVariableCancelSleep() would return early. ConditionVariableBroadcast() doesn't do that. -- Thomas Munro http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: