From: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: LWLocks in DSM memory |
Date: | 2016-07-28 04:12:44 |
Message-ID: | CAEepm=2ZSs01HMTskTD4YvMWeTqsKq0zM+M8iVV0-zWj1qof7w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jul 26, 2016 at 6:00 AM, Andres Freund <andres(at)anarazel(dot)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 | Content-Type | Size |
---|---|---|
lwlocks-in-dsm-v2.patch | application/octet-stream | 13.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2016-07-28 04:34:51 | Re: A Modest Upgrade Proposal |
Previous Message | Michael Paquier | 2016-07-28 02:38:33 | Re: A Modest Upgrade Proposal |