From owner-cvs-src@FreeBSD.ORG Wed Apr 2 01:10:01 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 3DD53106566B; Wed, 2 Apr 2008 01:10:01 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id EEA7F8FC1D; Wed, 2 Apr 2008 01:10:00 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [10.0.1.200] (cpe-24-94-72-120.hawaii.res.rr.com [24.94.72.120]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id m3219whv061389; Tue, 1 Apr 2008 21:09:59 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Tue, 1 Apr 2008 15:11:11 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Attilio Rao In-Reply-To: <3bbf2fe10804011723w69e38ed7sc5760ea269600654@mail.gmail.com> Message-ID: <20080401150918.F72156@desktop> References: <200804012031.m31KVtKs000176@repoman.freebsd.org> <200804020025.57684.max@love2party.net> <20080401123951.J72156@desktop> <200804020200.58006.max@love2party.net> <3bbf2fe10804011723w69e38ed7sc5760ea269600654@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 01:10:01 -0000 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. Readers are only allowed to proceed with a read lock if they already own a read lock, not just if the lock is already read locked. This changed in current recently. So a single recursive read acqusition can't deadlock but get multiple threads and a writer involved with writer preference and you can. Jeff > >> Can this deadlock? How? >> >> If thread C did: rw_wlock(RW) ... mtx_lock(MTX) ... UNLOCK or the other >> way around, I can see that it will[1] deadlock, but with the wlock >> without a lock order wrt the MTX, I can't see it. Plus, can we teach >> WITNESS to keep quite about thread A and B unless we also see a lock >> order with the wlock and the mutex? > > You mean skipping possible LORs for shared instances of double-sided primitives? > > Thanks, > Attilio > > > -- > Peace can only be achieved by understanding - A. Einstein >