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

From Tom Lane
Subject Re: Condition variable live lock
Date
Msg-id 23234.1515134575@sss.pgh.pa.us
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
Thomas Munro <thomas.munro@enterprisedb.com> writes:
> On Fri, Jan 5, 2018 at 7:10 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Should we rejigger the logic so that it awakens one additional waiter
>> (if there is one) after detecting that someone else has removed the
>> sentinel?  Obviously, this trades a risk of loss of wakeup for a risk
>> of spurious wakeup, but presumably the latter is something we can
>> cope with.

> One detail is that the caller of ConditionVariableSignal() got a true
> return value when it took out the sentinel (indicating that someone
> received the signal), and now when you call ConditionVariableSignal()
> because !aminlist there may be no one there.  I'm not sure if that's a
> problem.  For comparison, pthread_cond_signal() doesn't tell you if
> you actually signalled anyone.  Maybe the only reason we have that
> return code is so that ConditionVariableBroadcast() can use it the way
> it does in master...

Indeed, it looks like no other caller is paying attention to the result.
We could live with the uncertainty in the back branches, and redefine
ConditionVariableSignal as returning void in master.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: [HACKERS] SQL/JSON in PostgreSQL
Next
From: Alexander Korotkov
Date:
Subject: Re: [HACKERS] [PATCH] Incremental sort