Date: Wed, 5 Mar 2003 10:21:56 -0800 (PST) From: Nate Lawson <nate@root.org> To: John Baldwin <jhb@FreeBSD.org> Cc: 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.0303051002540.82805-100000@root.org> In-Reply-To: <XFMail.20030305115639.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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.0303051002540.82805-100000>