Neil Conway <[EMAIL PROTECTED]> writes: > LWLockRelease() currently does something like (simplifying a lot): > ... > This has the nice property that locks are granted in FIFO order. Is it > essential that we maintain that property?
Not really, although avoiding indefinite starvation is important. > If not, we could instead walk > through the wait queue and awaken *all* the shared waiters, and get a > small improvement in throughput. I think this would increase the odds of starvation for exclusive waiters significantly. It would also complicate the list manipulation in LWLockRelease, and the net loss of cycles to that might outweigh any possible speedup anyway. > 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. Uh, no; proc C will queue up behind proc B. See LWLockAcquire. Were this not so, again we'd be risking starving proc B, since there could easily be an indefinitely long series of people acquiring and releasing the lock in shared mode. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html