From owner-cvs-src@FreeBSD.ORG Wed Apr 2 10:05:36 2008 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93F241065672 for ; Wed, 2 Apr 2008 10:05:36 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by mx1.freebsd.org (Postfix) with ESMTP id 1B53E8FC2C for ; Wed, 2 Apr 2008 10:05:35 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by fg-out-1718.google.com with SMTP id 16so2619026fgg.35 for ; Wed, 02 Apr 2008 03:05:35 -0700 (PDT) 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=FmJg47EUCOl3xjg8kFBvO7OQ+0WEsDeDZOsl/NZibyk=; b=O4U0UVAYQ4xEGQQ+QLWjDHdB0xZZl7+QjnTWb1NDesdiorH4bapDUmzsKepz7uhaHomgf5tBe/oF1B0dzjOw3+nH/uds4YyeZcYUGoqZNd+OFNRhiKYold5sib3RBF3zJ+XWjqQQvCg812hjK7bDdEIQW4Lp8j2jOtWOUvDlM8w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=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=OJBK5Ar48MZg3OFLcpSyRKAjZqLnbYsi5wBLw42lfdMcZRsETEX5eKnzSBvlfXl0LtJvmmjR+NKxAu75lXMu6KINX5ftPHO+xPkOmWR6b0MU/5sgrb0+dpiwzzE0QjTens47A58GXDsTuHEmBUSgxPe3TYNP7CI1WuqIlcbfDjk= Received: by 10.86.82.16 with SMTP id f16mr6186649fgb.60.1207130734951; Wed, 02 Apr 2008 03:05:34 -0700 (PDT) Received: by 10.86.73.10 with HTTP; Wed, 2 Apr 2008 03:05:34 -0700 (PDT) Message-ID: <3bbf2fe10804020305r624ab142j18f00b84f2ae240f@mail.gmail.com> Date: Wed, 2 Apr 2008 12:05:34 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Jeff Roberson" In-Reply-To: <20080401150918.F72156@desktop> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200804012031.m31KVtKs000176@repoman.freebsd.org> <200804020025.57684.max@love2party.net> <20080401123951.J72156@desktop> <200804020200.58006.max@love2party.net> <3bbf2fe10804011723w69e38ed7sc5760ea269600654@mail.gmail.com> <20080401150918.F72156@desktop> X-Google-Sender-Auth: 53314ec7a23bd491 Cc: Max Laier , src-committers@freebsd.org, cvs-all@freebsd.org, cvs-src@freebsd.org Subject: Re: cvs commit: src/sys/kern kern_rwlock.c src/sys/sys rwlock.h X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2008 10:05:36 -0000 2008/4/2, Jeff Roberson : > > On Wed, 2 Apr 2008, Attilio Rao wrote: > > > > 2008/4/2, Max Laier : > > > > > On Wednesday 02 April 2008 00:52:45 Jeff Roberson wrote: > > > > On Wed, 2 Apr 2008, Max Laier wrote: > > > >> On Tuesday 01 April 2008 22:31:55 Attilio Rao wrote: > > > >>> attilio 2008-04-01 20:31:55 UTC > > > >>> > > > >>> FreeBSD src repository > > > >>> > > > >>> Modified files: > > > >>> sys/kern kern_rwlock.c > > > >>> sys/sys rwlock.h > > > >>> Log: > > > >>> Add rw_try_rlock() and rw_try_wlock() to rwlocks. > > > >>> These functions try the specified operation (rlocking and > > > >>> wlocking) and true is returned if the operation completes, false > > > >>> otherwise. > > > >> > > > >> hmmm ... I'm certainly missing something here, but what's a possible > > > >> usecase for these? It seems there is not much you can do if you > > > >> can't obtain a rw_lock. I can understand the need for sx_try_* where > > > >> you want to avoid sleeping, but I can't figure out the need for it on > > > >> a locking primitive that will only spin or wait (not 100% sure about > > > >> the terminology here). This is especially strange for rw_try_wlock, > > > >> unless you plan to sleep manually on fail. But then again you'd have > > > >> a good chance that you have to do it over and over again if timing is > > > >> unfortunate. > > > > > > > > I asked for it. We have a try operation for mtx already. I was > > > > experimenting with converting some code to use rwlocks from mtx and it > > > > required it. The specific case is in the softdep code where it uses > > > > trylock to avoid deadlocking. With trylock you can violate the > > > > lockorder. > > > > > > > > > Makes sense, thanks! A little follow-up, though about something I'm > > > wondering about for quite some time now. Take the following scenario: > > > > > > Thread A: rw_rlock(RW) ... mtx_lock(MTX) ... UNLOCK > > > Thread B: mtx_lock(MTX) ... rw_rlock(RW) ... UNLOCK > > > Thread C: rw_wlock(RW) ... UNLOCK > > > > > > > This can't deadlock simply because rw_rlock() is not mutually exclusive. > > > > It can deadlock if there is a writer waiting in queue depending on whether > we prefer readers or writers. I think we should consider the reader/writer > perference an implementation detail to prevent code like this from cropping > up. Ah, right, the writer starvation avoidance will lead to a deadlock here. Thanks, I didn't consider it, so it is still valid / better to treact read locks as all the other locks for WITNESS. Attilio -- Peace can only be achieved by understanding - A. Einstein