Re: Condition variable live lock

Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> writes:
> On Fri, Jan 5, 2018 at 7:10 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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