Date: Wed, 5 Mar 2003 12:10:45 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: Nate Lawson <nate@root.org> Cc: John Baldwin <jhb@FreeBSD.org>, cvs-all@FreeBSD.org, cvs-src@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_mutex.c Message-ID: <Pine.BSF.4.21.0303051209170.61509-100000@InterJet.elischer.org> In-Reply-To: <Pine.BSF.4.21.0303051002540.82805-100000@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0303051209170.61509-100000>