Neil Conway <neilc@samurai.com> 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
