On Fri, Jan 5, 2018 at 7:10 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I thought of another possible issue, though. In the situation where
> someone else has removed our sentinel (presumably, by issuing
> ConditionVariableSignal just before we were about to remove the
> sentinel), my patch assumes we can just do nothing. But it seems
> like that amounts to losing one signal. Whoever the someone else
> was probably expected to awaken a waiter, and now that won't happen.
Yeah, that's bad.
> 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...
An alternative would be to mark sentinel entries somehow so that
signallers can detect them and signal again, but that's not
backpatchable.
--
Thomas Munro
http://www.enterprisedb.com
