> There are ways of fixing the writer starvation and allowing recursive
> read locks, but that is more work (and heavier-weight than desirable).
One such way would be a variant of queued locks, like John Stultz's
http://oss.software.ibm.com/developer/opensource/linux/patches/?patch_id=218
These are usually needed for fairness even with plain spinlocks on NUMA
boxes in any case (so if your box is NUMA then you will need it anyways)
They only exist for plain spinlocks yet, but I guess they could be extended
to readlocks.
IIRC the benchmarks correctly they were about 3 times slower for the
uncontended case, but somewhat faster for contended locks. Of course
this is the wrong priority for linux - contended locks should be eliminated,
not optimized, but if there is no other choice for correctness it has to do.
> How pervasive are recursive reader locks? Should they be a special
> type of reader lock?
Not very common I hope, at least I cannot think of a case right now
(but then I don't claim to know all locks in linux)
Verifying that this case does not occur by code audit (or that
you have catched all instances if you made it a special case) would
be a lot of work: the 2.5.29 kernel has about 800 calls to read/write_lock
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/