Re: LogwrtResult contended spinlock

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: LogwrtResult contended spinlock
Дата
Msg-id 20200904170545.ko4bwixl3yuu5jxz@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: LogwrtResult contended spinlock  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: LogwrtResult contended spinlock
Список pgsql-hackers
Hi,

On 2020-09-03 14:34:52 -0400, Alvaro Herrera wrote:
> Looking at patterns like this
> 
>     if (XLogCtl->LogwrtRqst.Write < EndPos)
>         XLogCtl->LogwrtRqst.Write = EndPos;
> 
> It seems possible to implement with
> 
>     do {
>         XLogRecPtr    currwrite;
> 
>         currwrite = pg_atomic_read_u64(LogwrtRqst.Write);
>     if (currwrite > EndPos)
>             break;  // already done by somebody else
>         if (pg_atomic_compare_exchange_u64(LogwrtRqst.Write,
>                                        currwrite, EndPos))
>             break;  // successfully updated
>     } while (true);
> 
> This assumes that LogwrtRqst.Write never goes backwards, so it doesn't
> seem good material for a general routine.
> 
> This *seems* correct to me, though this is muddy territory to me.  Also,
> are there better ways to go about this?

Hm, I was thinking that we'd first go for reading it without a spinlock,
but continuing to write it as we currently do.

But yea, I can't see an issue with what you propose here. I personally
find do {} while () weird and avoid it when not explicitly useful, but
that's extremely minor, obviously.

Greetings,

Andres Freund



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Ranier Vilela
Дата:
Сообщение: Re: [PATCH] Redudant initilization
Следующее
От: Andres Freund
Дата:
Сообщение: Re: LogwrtResult contended spinlock