From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Neil Conway <neilc(at)samurai(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: lwlocks and starvation |
Date: | 2004-11-24 11:55:03 |
Message-ID: | 200411241155.iAOBt3k22338@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2004-11-24 12:18:23 | Re: lwlocks and starvation |
Previous Message | D'Arcy J.M. Cain | 2004-11-24 11:52:30 | Re: Trouble with plpgsql on 7.4.6 |