Re: LWLocks in DSM memory - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: LWLocks in DSM memory
Date
Msg-id CAEepm=2ZSs01HMTskTD4YvMWeTqsKq0zM+M8iVV0-zWj1qof7w@mail.gmail.com
Whole thread Raw
In response to Re: LWLocks in DSM memory  (Andres Freund <andres@anarazel.de>)
Responses Re: LWLocks in DSM memory
List 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

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: A Modest Upgrade Proposal
Next
From: David Fetter
Date:
Subject: Re: A Modest Upgrade Proposal