From owner-freebsd-arch@FreeBSD.ORG Sat Nov 24 00:35: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 C072916A420 for ; Sat, 24 Nov 2007 00:35:35 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by mx1.freebsd.org (Postfix) with ESMTP id 5524913C45D for ; Sat, 24 Nov 2007 00:35:35 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so2986374nfb for ; Fri, 23 Nov 2007 16:35:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=dV2nJyuQali5mgGHszBZSbwYCbB1VJUZpdcQd0vOOl8=; b=XNWlzH83/gREDDoLE+5uCHRqNLTcknnoV60NdIR1W41rReXhwnbI2jva1D2IbbsoXBiF+QHrjnf2axRuI6v8TSBMkz8ge0FwbeBjvzLoHURw2BLugee6lpwVIMn2tNIxt0ctS+9SQ4FTCEtPXMAma7dn9SjJwPVbbuJsluSj2tA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=JQxmtAoklEofprp13RfWSscVmWAGv2qLLEHo1PmRLuZ4J9/BGZPKvosGHiZaoBxhdJUwkbgxLNZhlryGwGijNnyp9PR/otHprwHv1/K/A7QdbLJUdfz4cLNsLbtuPEyguXRYew3KH77Tq11Z43xr6pZaYJRWOo4/s7SQ6nJLg+A= Received: by 10.86.4.2 with SMTP id 2mr10085452fgd.1195864533800; Fri, 23 Nov 2007 16:35:33 -0800 (PST) Received: by 10.86.28.19 with HTTP; Fri, 23 Nov 2007 16:35:33 -0800 (PST) Message-ID: <3bbf2fe10711231635i72df8babucedd1e5bdef7175d@mail.gmail.com> Date: Sat, 24 Nov 2007 01:35:33 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Robert Watson" In-Reply-To: <20071123235346.E14018@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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> <47469328.8020404@freebsd.org> <20071123092415.GP44563@elvis.mu.org> <4746F858.4070301@freebsd.org> <20071123235346.E14018@fledge.watson.org> X-Google-Sender-Auth: 28d0b9113e89c37d Cc: Stephan Uphoff , 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: Sat, 24 Nov 2007 00:35:35 -0000 2007/11/24, Robert Watson : > > On Fri, 23 Nov 2007, Stephan Uphoff wrote: > > >>> I talked with Attilio about that on IRC. Most common cases of writer > >>> starvation (but not all) could be solved by keeping a per thread count of > >>> shared acquired rwlocks. If a rwlock is currently locked as shared/read > >>> AND a thread is blocked on it to lock it exclusively/write - then new > >>> shared/read locks will only be granted to thread that already has a shared > >>> lock. (per thread shared counter is non zero) > >>> > >>> To be honest I am a bit twitchy about a lock without priority propagation > >>> - especially since in FreeBSD threads run with user priority in kernel > >>> space and can get preempted. > >> > >> That's an interesting hack, I guess it could be done. > >> > >> I would still like to disallow recursion. > >> > > Oh - I am all for disallowing recursion. In my opinion the only valid place > > for a thread to acquire the same lock multiple times is inside a transaction > > system with full deadlock detection. The question is if we can do that this > > late in the game? Maybe we could make non recursive the default and add a > > call rw_allow_recurse or rw_init_recurse to allow recursion on a lock if we > > can't get away with the straight out removal of the option? (Or less > > desirable - keep the current default and add functions to disallow > > recursion) > > While I'm no great fan of recursion, the reality is that many of our kernel > subsystems are not yet ready to disallow recursion on locks. Take a look at > the cases where we explicitly enable recursive acquisition for mutexes--in > practice, most network stack mutexes are recursive due to the recursive > calling in the network stack. While someday I'd like to think we'll be able > to eliminate some of that, but it won't be soon since it requires significant > reworking of very complicated code. The current model in which recursion is > explicitly enabled only where still required seems to work pretty well for the > existing code, although it's hard to say yet in the code I've looked at > whether read recursion would be required--the situations I have in mind would > require purely write recursion. There's one case in the UNIX domain socket > code where we do a locked test and conditional lock/unlock with an rwlock for > exclusive locking because recursion isn't currently supported, and that's not > a usage I'd like to encourage more of. I think however that Stephan is just referring to the readers recursion (as we are doing) that if present should be just in few points. If we want todo a radical switch of this genre this is the right moment, just before rwlock became too widespread. I have a patch against witness which would check for readers recursion and panic, I will post in the night or tomorrow. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein