Re: rwlocks, correctness over speed.

Alfred Perlstein wrote:
* Max Laier <max@xxxxxxxxxxxxxx> [071122 14:40] wrote:
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.

The problem is that there is no tracking in the common case (without
additional overhead), so you can't know if you're recursing, unless
you track it yourself.

recursion is hard for the caller to know because unrelated code could have done the original calls.
The only way it can know is if there is some generic recursion detection.


-Alfred

_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"

_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"

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.
    ... Before rwlocks were used, I had a handrolled locking that ... Only variant to allowread recursion and ... ... rwlock_rlockwhich would wait for the writer to enter and exit. ... priority propagation even for recursed readers. ...
    (freebsd-arch)
  • Re: rwlocks, correctness over speed.
    ... Before rwlocks were used, I had a handrolled locking that ... Only variant to allowread recursion and ... ... 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 failor do a normal rwlock_rlockwhich would wait for the writer to enter and exit. ...
    (freebsd-arch)