From owner-cvs-all Tue Mar 4 16:57:19 2003 Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 503E737B401; Tue, 4 Mar 2003 16:57:17 -0800 (PST) Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id 023F743FBD; Tue, 4 Mar 2003 16:57:16 -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 <2003030500571400100jaolqe>; Wed, 5 Mar 2003 00:57:15 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA54561; Tue, 4 Mar 2003 16:57:12 -0800 (PST) Date: Tue, 4 Mar 2003 16:57:11 -0800 (PST) From: Julian Elischer To: "Brian F. Feldman" Cc: John Baldwin , src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_mutex.c In-Reply-To: <200303042149.h24LnKSQ073292@green.bikeshed.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 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. Julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message