Neil Conway wrote:
> 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 exclusive lock,
> awaken him; else, walk through the queue and awaken
> all the shared waiters until we reach an exclusive waiter
> 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
> Proc C => LWLockAcquire(lock, LW_SHARED); -- succeeds
>
> i.e. we don't *really* follow strict FIFO order anyway.
My guess is the existing behavior was designed to allow waking of
multiple waiters _sometimes_ without starving of exclusive waiters.
There should be a comment in the code explaining this usage and I bet it
was intentional.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
