On Tue, Jul 26, 2016 at 6:00 AM, Andres Freund <and...@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
lwlocks-in-dsm-v2.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
