From owner-freebsd-hackers Tue Jan 5 13:13:00 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA08970 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 13:13:00 -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 NAA08963 for ; Tue, 5 Jan 1999 13:12:58 -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 NAA16996; Tue, 5 Jan 1999 13:43:36 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id NAA09607; Tue, 5 Jan 1999 13:43:35 -0700 Date: Tue, 5 Jan 1999 13:43:35 -0700 Message-Id: <199901052043.NAA09607@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Narvi Cc: Nate Williams , Terry Lambert , Wes =?iso-8859-1?Q?Peters=D4?=?=?iso-8859-1?Q?=40=21=EA?=? , bright@hotjobs.com, hackers@FreeBSD.ORG Subject: Re: question about re-entrancy. In-Reply-To: References: <199901052008.NAA09332@mt.sri.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > [snip] > > > > > > > > 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. > > > > > > > > > > > > > > > > Nate > > > > > > The third way (about which Terry did talk) is to have locks around > > > critical sections. > > > > That *is* what an 'object lock' in RTEMS is. > > > > An "object lock" is a lock associated with some object. In order to access > the object, you acquire the lock. > > A "critical section" lock is a lock associated with a certain critical > section of code. In order to enter that specific section of code, you > acquire the lock. A 'critical section of code' is a portion of the code that is accessing a shared resource, which can be protected by using an object lock. Or, better put you 'aquire a lock' before you enter the 'critical section' and 'release the lock' after you leave the critical section. (semaphores). Like I said, it's the same thing, just different terminology. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message