lwlocks and starvation - Mailing list pgsql-hackers

From Neil Conway
Subject lwlocks and starvation
Date
Msg-id 1101284611.12045.49.camel@localhost.localdomain
Whole thread Raw
Responses Re: lwlocks and starvation  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: lwlocks and starvation  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
LWLockRelease() currently does something like (simplifying a lot):
   acquire lwlock spinlock   decrement lock count   if lock is free     if first waiter in queue is waiting for
exclusivelock,     awaken him; else, walk through the queue and awaken     all the shared waiters until we reach an
exclusivewaiter   end if   release lwlock spinlock
 

This has the nice property that locks are granted in FIFO order. Is it
essential that we maintain that property? If not, we could instead walk
through the wait queue and awaken *all* the shared waiters, and get a
small improvement in throughput.

I can see that this might starve exclusive waiters; however, we allow
the following:
   Proc A => LWLockAcquire(lock, LW_SHARED); -- succeeds   Proc B => LWLockAcquire(lock, LW_EXCLUSIVE); -- blocks
ProcC => LWLockAcquire(lock, LW_SHARED); -- succeeds
 

i.e. we don't *really* follow strict FIFO order anyway.

-Neil




pgsql-hackers by date:

Previous
From: "Arnold.Zhu"
Date:
Subject: Re: How to make @id or $id as parameter name in plpgsql, is it available?
Next
From: Neil Conway
Date:
Subject: Re: Bitmap index