From owner-freebsd-hackers  Tue Jan  5 16:23:13 1999
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id QAA10509
          for freebsd-hackers-outgoing; Tue, 5 Jan 1999 16:23:13 -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 QAA10470
          for <hackers@FreeBSD.ORG>; Tue, 5 Jan 1999 16:23:09 -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 RAA19001;
	Tue, 5 Jan 1999 17:22:36 -0700 (MST)
	(envelope-from nate@rocky.mt.sri.com)
Received: by mt.sri.com (SMI-8.6/SMI-SVR4)
	id RAA11275; Tue, 5 Jan 1999 17:22:36 -0700
Date: Tue, 5 Jan 1999 17:22:36 -0700
Message-Id: <199901060022.RAA11275@mt.sri.com>
From: Nate Williams <nate@mt.sri.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Terry Lambert <tlambert@primenet.com>
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: <199901060019.RAA20813@usr05.primenet.com>
References: <199901052248.PAA10395@mt.sri.com>
	<199901060019.RAA20813@usr05.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

> > 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.)
> 
> [ ... ]
> 
> > > 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'?
> 
> See my other (recent) posting.
> 
> Basically, if you lock the code, you can enter the object multiple
> times for non-conflicting code, but if you lock the object, you can
> only enter it once.

Not necessarily.  A good locking implementation can realize that you've
already gotten the lock, and can let you continue to keep it.
(References, etc..)  Not too difficult to do, as long as you can
uniquely ID each individual 'thread of execution'.


Nate

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message