From owner-cvs-src@FreeBSD.ORG Wed Apr 2 00:23:25 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 80E2A106568A for ; Wed, 2 Apr 2008 00:23:25 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by mx1.freebsd.org (Postfix) with ESMTP id 001148FC33 for ; Wed, 2 Apr 2008 00:23:24 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by fg-out-1718.google.com with SMTP id 16so2419640fgg.35 for ; Tue, 01 Apr 2008 17:23:23 -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=Cv2i8D0EBXBzk/NDFknYW9oNaN+z9JRcXnEOOnHJEww=; b=OOOFnbRK9LfJcxAAOahPBIOMXs0rmEVboCMwvspi9eDBQwvj6W84OC5S6+vkYICfGhMGwen1E64ISwMsdL/XEfZhsEkKjXq6CTBayP4j91qdb2A/sqLdN8cKJLgoNrt+FxSAj1C3s5Z5NEDBtTGkbKCWtDkGWPywfOVlTheYsvo= 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=l8AzjfMebCfI2VLin6U8QtILrhM2mT6LMngiDQHxVcDrXSXlaI3L6eNrk1zg0ZzujomxLn/4szKkL7PcIkSLZ2AyYIHiBELgoT1eNq2wDURYbysVC89QFFACONP3Bb4TMQ2eRyd3hatXlK0Y2ABldMxTnVGMQI17mDVEL2TpFks= Received: by 10.86.51.2 with SMTP id y2mr5838735fgy.15.1207095803816; Tue, 01 Apr 2008 17:23:23 -0700 (PDT) Received: by 10.86.73.10 with HTTP; Tue, 1 Apr 2008 17:23:23 -0700 (PDT) Message-ID: <3bbf2fe10804011723w69e38ed7sc5760ea269600654@mail.gmail.com> Date: Wed, 2 Apr 2008 02:23:23 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Max Laier" In-Reply-To: <200804020200.58006.max@love2party.net> 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> X-Google-Sender-Auth: 889e7848b7dd8c3b Cc: Jeff Roberson , 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 00:23:25 -0000 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. > 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