Date: Tue, 5 Jan 1999 17:22:36 -0700 From: Nate Williams <nate@mt.sri.com> 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. Message-ID: <199901060022.RAA11275@mt.sri.com> In-Reply-To: <199901060019.RAA20813@usr05.primenet.com> References: <199901052248.PAA10395@mt.sri.com> <199901060019.RAA20813@usr05.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901060022.RAA11275>