From owner-cvs-src Wed Mar 5 11:40:40 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 C8AB937B405; Wed, 5 Mar 2003 11:40:35 -0800 (PST) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D3AC43F75; Wed, 5 Mar 2003 11:40:34 -0800 (PST) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by rwcrmhc51.attbi.com (rwcrmhc51) with ESMTP id <2003030519403205100iq22de>; Wed, 5 Mar 2003 19:40:33 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA61973; Wed, 5 Mar 2003 11:40:32 -0800 (PST) Date: Wed, 5 Mar 2003 11:40:30 -0800 (PST) From: Julian Elischer To: John Baldwin Cc: cvs-all@FreeBSD.org, cvs-src@FreeBSD.org, src-committers@FreeBSD.org, "Brian F. Feldman" 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, John Baldwin wrote: > > On 05-Mar-2003 Julian Elischer wrote: > > > > > > On Tue, 4 Mar 2003, Brian F. Feldman wrote: > > 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. > The case I was using it for was basically: if (!mtx_trylock(foo)) { queue_data_for_later_proccessing(data) return; } do_the_work_immediatly(); where it was possible that I had called myself as part of do_the_work_immediatly() and wanted it to complete immediatly since I knew I already owned the object. I can see that in other cases you would want the alternative behaviour however. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-src" in the body of the message