From owner-cvs-src Wed Mar 5 8:56:33 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 AEE5A37B401 for ; Wed, 5 Mar 2003 08:56:29 -0800 (PST) Received: from mail.speakeasy.net (mail16.speakeasy.net [216.254.0.216]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC8C343FAF for ; Wed, 5 Mar 2003 08:56:25 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 24208 invoked from network); 5 Mar 2003 16:56:29 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail16.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 5 Mar 2003 16:56:29 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.6/8.12.6) with ESMTP id h25GrjhT048819; Wed, 5 Mar 2003 11:53:46 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Wed, 05 Mar 2003 11:56:39 -0500 (EST) From: John Baldwin To: Julian Elischer Subject: Re: cvs commit: src/sys/kern kern_mutex.c Cc: cvs-all@FreeBSD.org, cvs-src@FreeBSD.org, src-committers@FreeBSD.org, "Brian F. Feldman" 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 05-Mar-2003 Julian Elischer wrote: > > > On Tue, 4 Mar 2003, Brian F. Feldman wrote: > >> John Baldwin wrote: >> > already own. The mtx_trylock() will fail however. Enhance the comment >> > at the top of the try lock function to explain this. >> > >> I admit I've never actually had a use for mtx_trylock() but... wouldn't you >> like to detect it and assert against it if you're not expecting it? If >> jlemon's behavior is the only one that relies on that part of the semantics, >> perhaps it should be another kind of mtx_trylock() call. I guess the real >> question is just whether or not the assert would ever have done good for >> anyone while working. > > > > It's a bit late, but it seems a it !POLA to have mtx_try_lock() fail in > a situation where mtx_lock() would succeed. ? > > I have used try_lock once, though I eventually did it anouther way. > > I have always thougth of try_lock as being > "Try, but instead of sleeping, come back so I can try something else > instead." The implicit message here is that if 'lock()' > would succeed, try_lock() would succeed.. If you already own the lock, you should know that you already own the lock in almost all cases, in which case you know you can safely call mtx_lock() without blocking. mtx_lock() won't block on a lock you already own. > If you don't want this then maybe it should be called > "try_lock_no_recurse()" or something.. > Or maybe the lock should be labled as non-recursive, so that > the normal lock fails as well. I can't retroactively label a lock non-recursive once trylock() is called on it. :) Not without non-deterministic witness checking. mtx_trylock() really should be used sparingly I think. I don't want people doing this: if (!mtx_trylock(foo)) tsleep(...); 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. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-src" in the body of the message