rwlocks, correctness over speed.

[Attilio Rao]

2007/11/22, Max Laier <max at love2party.net>:
>
> rwlocks are already used in places that do recursive reads.  The one place
> I'm certain about is pfil(9) and we need a proper sollution for this.
> Before rwlocks were used, I had a handrolled locking that supported both
> read/write semantics and starvation avoidance - at the cost of failing to
> allow futher read access when a writer asked for access.  This however,
> was quite application specific and not the most efficient implementation
> either.

I'm not a pfil(9) expert, but for what I've heard, rmlocks should be
really good for it, shouldn't them?

The concept is that if we want to maintain fast paths for rwlock we
cannot do too much tricks there. And you can really deadlock if you
allow recursion on readers...

> If we were to disallow read recursion, we should have some generic lock
> type that does allow it.  rmlock(9)s seem to support full priority
> propagation even for recursed readers.  Can they be MFCed so that we have
> an alternative?  Are they considered ready for production?  Should we
> switch pfil(9) to them?  It seems like a perfect match.

I've not looked over rmlocks so much, but as they track readers they
can do priority propagation (if it is not implemented, it could be
done -- not sure about the cost of the operation though).

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein