From owner-freebsd-arch@FreeBSD.ORG Sat Nov 24 13:53:54 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 2CAC816A419 for ; Sat, 24 Nov 2007 13:53:54 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by mx1.freebsd.org (Postfix) with ESMTP id A890513C4F6 for ; Sat, 24 Nov 2007 13:53:53 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so113442nfb for ; Sat, 24 Nov 2007 05:53:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=ZO7I8AWAyDFhPEqV2BwrLSTzjBtXz7hZ9OAbTU9wpTk=; b=Sjk+bMcmXKITy3qTyOE6YJXTSryH+ly1WyBFvlRmKzXKBZTEaWO77f+OS9Je+cFJcxg2UrQjsWnVEB4mXH3YeG0nZPryCLVX+taIWb94+g9RMFpgnqznWOA0O8ItFFs35IRtpC9DMwxTkSo9yP7uWp+7vjie+WVMllXDIABkmEI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; 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=eTtzrqALmiUFmUshKcBCkijO8KiAC7Io8ZRqg5UnJbLUXPdJZuCXDO4AXkdKxoFI91TQ6rCeI6JdurhpP5Uj5CjKgOnctabGav5ZEiMy09F0In8wKCoNiMDvT4zMj+oWimjuuAcybFqNAhtXFV81W7e7p50mIst4Gri0yPZIcfY= Received: by 10.86.98.18 with SMTP id v18mr531002fgb.1195912432243; Sat, 24 Nov 2007 05:53:52 -0800 (PST) Received: by 10.86.28.19 with HTTP; Sat, 24 Nov 2007 05:53:52 -0800 (PST) Message-ID: <3bbf2fe10711240553k1eb35a5au23cae8af08f5864c@mail.gmail.com> Date: Sat, 24 Nov 2007 14:53:52 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Robert Watson" In-Reply-To: <20071124103231.A14018@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> <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> <3bbf2fe10711231930m459dc800wbbb894b9fd50ca13@mail.gmail.com> <20071124103231.A14018@fledge.watson.org> X-Google-Sender-Auth: 828272a9965bc456 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 13:53:54 -0000 2007/11/24, Robert Watson : > On Sat, 24 Nov 2007, Attilio Rao wrote: > > > 2007/11/24, Robert Watson : > > > >> 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. > > > > Oh, I just didn't notice this -- rwlock are only present in 7.0 and in 7.0 > > they support recursion in exclusive mode, so I'm not sure what do you mean > > with 'recursion isn't currently supported'. > > I must have missed recursion arriving then -- I'll modify uipc_usrreq.c to set > the recursion flag on the rwlock in UNIX domain sockets rather than doing the > nasty hack that was previously required. At the time, the hack was added > because it seemed recursion was not going to be added to rwlocks, but > sonewconn() behavior for listen sockets really ended up requiring it. attilio 2007-06-26 21:31:56 UTC FreeBSD src repository Modified files: sys/kern kern_rwlock.c sys/sys _rwlock.h rwlock.h Log: Introduce a new rwlocks initialization function: rw_init_flags. This is very similar to sx_init_flags: it initializes the rwlock using special flags passed as third argument (RW_DUPOK, RW_NOPROFILE, RW_NOWITNESS, RW_QUIET, RW_RECURSE). Among these, the most important new feature is probabilly that rwlocks can be acquired recursively now (for both shared and exclusive paths). Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein