Date: Thu, 22 Nov 2007 16:53:28 +0100 From: "Attilio Rao" <attilio@freebsd.org> To: "Max Laier" <max@love2party.net> Cc: Stephan Uphoff <ups@freebsd.org>, Alfred Perlstein <alfred@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: rwlocks, correctness over speed. Message-ID: <3bbf2fe10711220753u435ff4cbxa94d5b682292b970@mail.gmail.com> In-Reply-To: <200711221641.02484.max@love2party.net> References: <20071121222319.GX44563@elvis.mu.org> <200711221641.02484.max@love2party.net>
next in thread | previous in thread | raw e-mail | index | archive | help
2007/11/22, Max Laier <max@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3bbf2fe10711220753u435ff4cbxa94d5b682292b970>