Re: rwlocks, correctness over speed.

2007/11/21, Alfred Perlstein <alfred@xxxxxxxxxxx>:
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.

As we alredy discussed on IRC, I'm for assuming no recursion on
readers (recursion on writers doesn't play any role here, so it is ok
maintaining the current behaviour) and adding a mechanism to WITNESS
in order to catch cases where such condition is violated.
In this way we don't penalyze fast cases.

Do you alredy have a patch for the wakeup / sleeping algorithm?

Thanks,
Attilio


--
Peace can only be achieved by understanding - A. Einstein
_______________________________________________
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: 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[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.
    ... 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)
  • 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)