From owner-freebsd-arch@FreeBSD.ORG Fri Nov 23 16:34:35 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 B901116A420 for ; Fri, 23 Nov 2007 16:34:35 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outM.internet-mail-service.net (outM.internet-mail-service.net [216.240.47.236]) by mx1.freebsd.org (Postfix) with ESMTP id 7C2F513C4DB for ; Fri, 23 Nov 2007 16:34:35 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Fri, 23 Nov 2007 08:34:29 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id C35A4126ABD; Fri, 23 Nov 2007 08:34:26 -0800 (PST) Message-ID: <47470112.8090005@elischer.org> Date: Fri, 23 Nov 2007 08:34:26 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Alfred Perlstein References: <20071121222319.GX44563@elvis.mu.org> <200711221641.02484.max@love2party.net> <3bbf2fe10711220753u435ff4cbxa94d5b682292b970@mail.gmail.com> <200711221726.27108.max@love2party.net> <20071123082339.GN44563@elvis.mu.org> <4746FC5B.3040809@elischer.org> In-Reply-To: <4746FC5B.3040809@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Attilio Rao , Max Laier , Stephan Uphoff , 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: Fri, 23 Nov 2007 16:34:35 -0000 Julian Elischer wrote: > Alfred Perlstein wrote: >> * Max Laier [071122 14:40] wrote: >>> On Thursday 22 November 2007, 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... >>> 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. translation: make recursion as hard as possible, (or disallow) > >> >> -Alfred >> >> _______________________________________________ >> freebsd-arch@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arch >> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"