Re: rwlocks, correctness over speed.

On Thursday 22 November 2007, Attilio Rao wrote:
2007/11/22, Max Laier <max@xxxxxxxxxxxxxx>:
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...

How about adding rwlock_try_rlock() which would do the following:
1) Only variant to allow[1] read recursion and ...
2) ... only if no outstanding write requests
3) Let the caller deal with failure

This can be implemented statically, so no overhead in the fast path. The
caller is in the best position to decide if it is recursing or not -
could keep that info on the stack - and can either fail[2] or do a normal
rwlock_rlock() which would wait for the writer to enter and exit.

[2] In most situation where you use read locks you can fail or roll back
carefully as you didn't change anything - obviously. In pfil - for
instance - we just dropped the packet if there was a writer waiting.

[1] "allow" in terms of WITNESS - if that can be done.

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



--
/"\ Best regards, | mlaier@xxxxxxxxxxx
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | mlaier@EFnet
/ \ ASCII Ribbon Campaign | Against HTML Mail and News

Attachment: signature.asc
Description: This is a digitally signed message part.

Relevant Pages

  • Re[2]: rwlocks, correctness over speed.
    ... It's not the matter of recursion, ... locks once a writer has blocked on the lock. ... we were to block readers once a writer blocked and a reader ... We currently have a problem with our implementation of rwlocks. ...
    (freebsd-arch)
  • Re: rwlocks, correctness over speed.
    ... It's not the matter of recursion, ... locks once a writer has blocked on the lock. ... We currently have a problem with our implementation of rwlocks. ... We do not support writer priority or "fair share" usage of rwlocks ...
    (freebsd-arch)
  • Re: rwlocks, correctness over speed.
    ... It's not the matter of recursion, ... locks once a writer has blocked on the lock. ... We currently have a problem with our implementation of rwlocks. ... We do not support writer priority or "fair share" usage of rwlocks ...
    (freebsd-arch)
  • Re: rwlocks, correctness over speed.
    ... We currently have a problem with our implementation of rwlocks. ... We do not support writer priority or "fair share" usage of rwlocks ... Disallow recursion on rwlocks, ...
    (freebsd-arch)
  • Re: rwlocks, correctness over speed.
    ... Before rwlocks were used, I had a handrolled locking that supported both ... allow recursion on readers... ... propagation even for recursed readers. ... can do priority propagation (if it is not implemented, ...
    (freebsd-arch)