From owner-cvs-src@FreeBSD.ORG Wed Apr 2 07:14:13 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 A67FD106566B; Wed, 2 Apr 2008 07:14:13 +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 7AE498FC2A; Wed, 2 Apr 2008 07:14:13 +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 m327EAnk007662; Wed, 2 Apr 2008 03:14:11 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Tue, 1 Apr 2008 21:15:25 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Max Laier In-Reply-To: <200804020412.30624.max@love2party.net> Message-ID: <20080401210738.E72156@desktop> References: <200804012031.m31KVtKs000176@repoman.freebsd.org> <3bbf2fe10804011723w69e38ed7sc5760ea269600654@mail.gmail.com> <20080401150918.F72156@desktop> <200804020412.30624.max@love2party.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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-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 07:14:13 -0000 On Wed, 2 Apr 2008, Max Laier wrote: > On Wednesday 02 April 2008 03:11:11 Jeff Roberson wrote: >> 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. > > Sorry, I still don't understand this. Even if there is a writer (thread > C) waiting and we prefer writers, the reader (A or B) has to wait, but > eventually the writer will give up the lock (as it can make progress > independently of whether the mutex is held or not) and the readers can > progress. What am I missing? Thread A: rw_rlock(RW) ... mtx_lock(MTX) ... UNLOCK Thread B: mtx_lock(MTX) ... rw_rlock(RW) ... UNLOCK Thread C: rw_wlock(RW) ... UNLOCK Thread A: Thread B: Thread C: rw_rlock(rw) mtx_lock(mtx) rw_wlock(rw) <- Blocked waiting for a rw_rlock(rw) <- Blocked waiting for c due to write fairness mtx_lock(mtx) <- Blocked waiting for B Does that help? > > I don't think this is a good thing either, but I also think that there are > some cases where there just are different access orders. I'd rather want > a clean way out of this than a lot of difficult per-instance hacks. This > does not mean that these can't be fixed cleanly, but I think it's really > hard sometimes especially for code we import from elsewhere (hence the > personal interest). I think the best solution is to treat rlocks as wlocks in terms of access orders. > >> 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. Thanks, Jeff > > -- > /"\ Best regards, | mlaier@freebsd.org > \ / Max Laier | ICQ #67774661 > X http://pf4freebsd.love2party.net/ | mlaier@EFnet > / \ ASCII Ribbon Campaign | Against HTML Mail and News >