The wiki todo has the topic "Fix priority ordering of read and write
light-weight locks" and
references http://archives.postgresql.org/pgsql-hackers/2004-11/msg00893.php
(lwlocks and starvation)
Having read the referenced discussion, I'm trying to figure out what
remains to be done. Tom proposed a patch back in 2004, which still
seems rather applicable today, which would correct the "new Shared
request trumps queued Exclusive waiter" problem except for not fixing
it during a race condition. It seems that this patch was not pursued
because no one thought it was evident that it would actually make
things better (is Exclusive Waiter starvation actually a documentable
problem?), while the ways it could make things worse are obvious
(adding a context switches, often to little end).
So what is waiting to be done?
Do we want a fix that doesn't suffer the race condition (a waiter has
been removed from the queue
and signaled, but has not yet been dispatched to the CPU)? It is hard
to imagine one of those that is not worse than the disease.
Are we looking for empirical evidence that the proposed patch is
actually an improvement for at least one plausible workload? In which
case, does anyone have suggestions about what such a work-load might
look like?
Since lwlock covers a rather heterogeneous bunch of lock purposes, it
seems unlikely to me any one strategy is going to be applicable to all
of those purposes if extreme optimization is what we are after . How
much are we willing to sacrifice modularity and abstraction in order
to get a little extra performance out of things protected by lwlock?
Cheers,
Jeff
