Re: [PATCH] Reduce LWLockWaitListLock() cache-line contention with adaptive spin reads

Hi All,

What about a light-weight-lock-wait-list-wait-list.

One of the steps to reduce contention on the LWLocks was to pad LWLocks to
give each lock its own cache line.
/* Main array of LWLocks in shared memory */
LWLockPadded *MainLWLockArray = NULL;

So, if we are allocating extra memory, could we use space as a buffer
for the wait list? Add to the buffer with an atomic increment on a counter,
and set ProcID and action on a given slot.

DRAFT
======

Use a bit in the state to indicate that the lock has that space. Even if
locked
it can add to the buffer with a finite set of operations.

If we constrain the LWLockDequeueSelf to only touch the buffer, i.e.
put on the buffer on LWLockQueueSelf, clear entry form the buffer only

Each entry is the ProcID+{head,tail,temp}.
LWLockWakeup could clear the temp and leave it on the buffer or
move to the proclist. In that case the only deletion from the middle of the
queue
will only happen in LWLockWakeup. Insert/Delete from head/tail can be
performed
with a CAS.

If QueueSelf sees the buffer full it can evict any non-temp entry to the
proclist,
this can be done atomically, so no lock required either.

In this algorithm the only locks left are
(1) LWLockQueueSelf with a buffer full of temp entries.
(2) LWLockWakeup

And they are waiting on different resources, one waits for space
in the buffer and the other waits for exclusive access on the proclist.

Not sure if LWLockWakeup needs the lock either, or the LWLockWakeup
from LWLockRelease is enough to prevent concurrency?
Maybe instead of viewing that as a lock, view it as a skip (someone is
doing what we would do either way).

Regards,
Alexandre