From owner-freebsd-arch@FreeBSD.ORG Thu Nov 22 19:04:31 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82EA516A46C for ; Thu, 22 Nov 2007 19:04:31 +0000 (UTC) (envelope-from ups@freebsd.org) Received: from smtpout08.prod.mesa1.secureserver.net (smtpout08-04.prod.mesa1.secureserver.net [64.202.165.12]) by mx1.freebsd.org (Postfix) with SMTP id 701F213C478 for ; Thu, 22 Nov 2007 19:04:31 +0000 (UTC) (envelope-from ups@freebsd.org) Received: (qmail 25194 invoked from network); 22 Nov 2007 18:37:47 -0000 Received: from unknown (66.23.216.53) by smtpout08-04.prod.mesa1.secureserver.net (64.202.165.12) with ESMTP; 22 Nov 2007 18:37:47 -0000 Message-ID: <4745CC84.3040600@freebsd.org> Date: Thu, 22 Nov 2007 13:37:56 -0500 From: Stephan Uphoff User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Attilio Rao References: <20071121222319.GX44563@elvis.mu.org> <200711221641.02484.max@love2party.net> <3bbf2fe10711220753u435ff4cbxa94d5b682292b970@mail.gmail.com> In-Reply-To: <3bbf2fe10711220753u435ff4cbxa94d5b682292b970@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Max Laier , Alfred Perlstein , freebsd-arch@freebsd.org Subject: Re: rwlocks, correctness over speed. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2007 19:04:31 -0000 Attilio Rao wrote: > 2007/11/22, Max Laier : > >> 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). > Yes - rmlock does priority propagation to readers. (One reader at a time until no more readers are left) > Attilio > > >