Re: LWLocks in DSM memory

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: LWLocks in DSM memory
Дата
Msg-id CAEepm=2ZSs01HMTskTD4YvMWeTqsKq0zM+M8iVV0-zWj1qof7w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: LWLocks in DSM memory  (Andres Freund <andres@anarazel.de>)
Ответы Re: LWLocks in DSM memory  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Tue, Jul 26, 2016 at 6:00 AM, Andres Freund <andres@anarazel.de> wrote:
> I think the better fix here would acutally be to get rid of a pointer
> based list here, and a) replace the queue with integer offsets ...

Here is a prototype of that idea.  It replaces that dlist with a
proclist, a new specialised doubly-linked list for pgprocno values,
using INVALID_PGPROCNO for termination.  It works with proclist_node
objects inside PGPROC at an arbitrary offset which must be provided
when you initialise the proclist.

It could be made more general than just the PGPROC array by taking the
base address and stride of the array, perhaps even allowing for a
different base address in each backend for arrays that live in DSM,
but I happened to see https://xkcd.com/974/ today and didn't pursue
that thought.

> ... b) make
> the queue lock-free.  But I understand that you might not want to tackle
> that :P

This may be complicated by the not-strictly-queue-like access pattern.
I haven't looked into it yet, but I can see that it requires some
serious study (Harris or Zhang techniques, maybe with extra tagging to
avoid ABA problems on concurrent removal of the same node?, and if so
that might require a wider CAS than we have?).

I wonder if a proclist with an optional lock-free interface would also
be interesting for syncrep queues and others.

--
Thomas Munro
http://www.enterprisedb.com

Вложения

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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: A Modest Upgrade Proposal
Следующее
От: David Fetter
Дата:
Сообщение: Re: A Modest Upgrade Proposal