From owner-freebsd-hackers Tue Jan 5 14:48:56 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA23914 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 14:48:56 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA23899 for ; Tue, 5 Jan 1999 14:48:54 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id PAA18115; Tue, 5 Jan 1999 15:48:22 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id PAA10395; Tue, 5 Jan 1999 15:48:22 -0700 Date: Tue, 5 Jan 1999 15:48:22 -0700 Message-Id: <199901052248.PAA10395@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Terry Lambert Cc: nate@mt.sri.com (Nate Williams), wes@softweyr.com, bright@hotjobs.com, hackers@FreeBSD.ORG Subject: Re: question about re-entrancy. In-Reply-To: <199901052242.PAA24752@usr02.primenet.com> References: <199901051946.MAA09199@mt.sri.com> <199901052242.PAA24752@usr02.primenet.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > The problem with object locks is that it puts > > > objects that don't really need to be in a contention > > > domain into one in order to satisfy contention in what > > > are usually very small critical sections having to do > > > with list manipulation of pointers to the object. > > > > So you're claiming that the 'Big Giant Lock' is the better way? You > > can't have it both ways. > > No. I'm claiming critical section locks tend to be held for a > shorter duration than an object tends to be held (this should be > intuitively obvious -- critical sections are less persistant than > objects which are operated upon by both critical (redcode) and noncritical > sections). Huh? Differentiate between 'protecting a critical section and using object locks?'. (Assumin that 'aquire' with no parameters block indefinitely until the lock is gained. If you want something else, use something else.) Object lock = new Object(); lock.aquire(); /* Critical section */ lock.release(); This is the same thing you are stating, which you claim is somehow inferior to some other way of locking down a critical section of code. (This is how you would do this in RTEMS.) > Having critical sections that can be locked WITH THEIR OWN INIDIVIDUAL > LOCKS is a far cry from suggesting that critical sections should be > protected with The Big Giant Lock(tm). And you can use 'individual locks' inside RTEMS. How is this different than 'locking down critical sections w/out using object locks'? Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message