Re: Condition variable live lock

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Condition variable live lock
Дата
Msg-id 23234.1515134575@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Condition variable live lock  (Thomas Munro <thomas.munro@enterprisedb.com>)
Ответы Re: Condition variable live lock
Список 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 по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: [HACKERS] SQL/JSON in PostgreSQL
Следующее
От: Alexander Korotkov
Дата:
Сообщение: Re: [HACKERS] [PATCH] Incremental sort