Re: Condition variable live lock - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Condition variable live lock
Date
Msg-id CAEepm=1jfBU6F6aW-uvt+c698TmcwsjYhS8jC47YAvm6=kE7qQ@mail.gmail.com
Whole thread Raw
In response to Re: Condition variable live lock  (Thomas Munro <thomas.munro@enterprisedb.com>)
Responses Re: Condition variable live lock
List 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 by date:

Previous
From: Antonin Houska
Date:
Subject: Re: [HACKERS] [PATCH] Incremental sort
Next
From: Michael Paquier
Date:
Subject: Re: pgsql: Implement channel binding tls-server-end-point for SCRAM