Date: Tue, 5 Jan 1999 15:48:22 -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: <199901052248.PAA10395@mt.sri.com> In-Reply-To: <199901052242.PAA24752@usr02.primenet.com> References: <199901051946.MAA09199@mt.sri.com> <199901052242.PAA24752@usr02.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901052248.PAA10395>