From owner-cvs-src Wed Mar 5 12:10:52 2003 Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFD4B37B401; Wed, 5 Mar 2003 12:10:49 -0800 (PST) Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id A6B3743FB1; Wed, 5 Mar 2003 12:10:48 -0800 (PST) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by sccrmhc01.attbi.com (sccrmhc01) with ESMTP id <2003030520104700100j8tq9e>; Wed, 5 Mar 2003 20:10:47 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA62216; Wed, 5 Mar 2003 12:10:46 -0800 (PST) Date: Wed, 5 Mar 2003 12:10:45 -0800 (PST) From: Julian Elischer To: Nate Lawson Cc: John Baldwin , cvs-all@FreeBSD.org, cvs-src@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_mutex.c In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-src@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 5 Mar 2003, Nate Lawson wrote: > On Wed, 5 Mar 2003, John Baldwin wrote: > > If they want to block on a lock they should use mtx_lock(). Cases > > where one might use mtx_trylock() that I can think of is for > > optional optimizations for cases that might otherwise be a lock > > order violation. I.e., if I can lock two X objects, then I can > > bypass having to lock one, stick it on a queue so that some other > > thread can connect it to the other. The only time I have used it > > is in the OOM killer where I need to be able to lock a process I > > am checking while keeping the current target process locked for > > the whole loop. Really, I want the programmer to think carefully > > when they use mtx_trylock() and blindly recursing on a lock might > > result in some hard to track down bugs. > > I have a situation where I am not quite sure if mtx_trylock() is the right > answer. There is a single-phase process for SCSI target instances where > you create a named endpoint and then enable traffic to it. On the disable > route, it is 2-phase where you disable traffic and abort all outstanding > commands. Later, you close the device and the endpoint is freed. The > endpoint needs to stay allocated to accept freed resources as they are > released by aborted commands. > > My issue is with contention for a named endpoint. If one thread enables > traffic to an endpoint and then disables it, it still has the endpoint > allocated. If another thread tries to enable the same endpoint, it needs > to lock the OTHER endpoint, check if it's disabled (freeing it if it is), > and then unlock it. My current locking approach is to lock my own softc, > lock the driver global mtx, and then lock the OTHER thread's softc before > checking if it is enabled. This is very similar to the case I was trying to solve.. I was trying to create and destroy netgraph links. from different ends of the connection.. I ended up taking a completely different approach. :-) > > Code is in targioctl(), targenable() and targdisable(). Is this an > appropriate way? Suggestions? > > -Nate > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-src" in the body of the message