rwlocks, correctness over speed.
Max Laier
max at love2party.net
Thu Nov 22 07:46:17 PST 2007
On Wednesday 21 November 2007, Alfred Perlstein wrote:
> In summary, I am proposing (temporarily) making read-recursion
> on rwlocks not supported in order to avoid livelock due to writer
> starvation.
>
> More details:
>
> We currently have a problem with our implementation of rwlocks.
>
> I think this is a key issue for 7.x as what we decide to support
> will have rammifications for many years to come.
>
> We do not support writer priority or "fair share" usage of rwlocks
> between readers and writers.
>
> We have several choices to rectify this.
>
> 1. Disallow recursion on rwlocks (witness can be used to enforce this),
> this simplifies rwlocks such that we can avoid deadlock when a single
> reader is trying to recurse while a writer is pending.
>
> 2. Track ownership of rwlocks, this can be implemented with a "rwlock
> stack" in the per-thread control block (struct thread). Using this
> ownership information we can determine if someone is recursing and
> allow them to continue recursing despite a pending write request.
>
> I think the most simple solution currently is to drop support for
> recursive reads on rwlocks until we have the facility in place
> to properly support starvation avoidance.
>
> Why is this important?
>
> Simply put, developers that quickly "fix" some portion of code,
> whether that be a driver or part of the kernel proper who use read
> recursion will open the system to writer starvation and hence the
> system will destabilize, particulary for high load situations.
>
> I would like to get this in before 7.0-RELEASE becasue otherwise
> we're forced to implement something like the above mentioned solution
> #2, which will degrade performance for most use cases of rwlocks.
>
> Comments?
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.
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.
Obviously rmlocks are not a general replacement for rwlocks, but in the
case of pfil they are the even better fit.
--
/"\ Best regards, | mlaier at freebsd.org
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | mlaier at EFnet
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20071122/62be0884/attachment.pgp
More information about the freebsd-arch
mailing list