From owner-cvs-all@FreeBSD.ORG Wed Apr 2 00:03:07 2008 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6BE8B1065678 for ; Wed, 2 Apr 2008 00:03:07 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.174]) by mx1.freebsd.org (Postfix) with ESMTP id 02DBC8FC2B for ; Wed, 2 Apr 2008 00:03:06 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-067-234-219.pools.arcor-ip.net [88.67.234.219]) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis) id 0MKwtQ-1JgqRV2rKx-0002bL; Wed, 02 Apr 2008 02:03:05 +0200 Received: (qmail 55145 invoked from network); 2 Apr 2008 00:02:09 -0000 Received: from myhost.laiers.local (192.168.4.151) by router.laiers.local with SMTP; 2 Apr 2008 00:02:09 -0000 From: Max Laier Organization: FreeBSD To: Jeff Roberson Date: Wed, 2 Apr 2008 02:00:57 +0200 User-Agent: KMail/1.9.9 References: <200804012031.m31KVtKs000176@repoman.freebsd.org> <200804020025.57684.max@love2party.net> <20080401123951.J72156@desktop> In-Reply-To: <20080401123951.J72156@desktop> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200804020200.58006.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1/ipBjzp1UCuKbSFuTmhszDIIdSPNGlEfrafRq q2m2WeZXPna8GHbTqnmBTD9G/AqKxrm8xJHL6osUF3crckY8F4 2Bf5Sg5QPEBN7IOfns3+Q== Cc: Attilio Rao , cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/kern kern_rwlock.c src/sys/sys rwlock.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2008 00:03:07 -0000 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 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? [1] In fact, thinking about it right now ... if thread C did: mtx_lock(MTX) ... rw_slock(RW) ... UNLOCK it might still be okay. IIRC we allow rlocks to succeed as long as there are other rlocks held. Though this might be historical behavior to support recursion. I see that we wouldn't want to rely on this to avoid live locks. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News