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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
