Date: Wed, 6 Jan 1999 00:19:25 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: nate@mt.sri.com (Nate Williams) Cc: tlambert@primenet.com, nate@mt.sri.com, wes@softweyr.com, bright@hotjobs.com, hackers@FreeBSD.ORG Subject: Re: question about re-entrancy. Message-ID: <199901060019.RAA20813@usr05.primenet.com> In-Reply-To: <199901052248.PAA10395@mt.sri.com> from "Nate Williams" at Jan 5, 99 03:48:22 pm
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. So if I had one CPU responding to a disk controller interrupt to update the pages hung of a vnode as a result of a demand page, and I had another CPU that wanted to assert an advisory lock on the vnode, the second CPU would have to wait to access the vnode using object locks, but it wouldn't have to wait using critical section locks becuase the operations each CPU wanted to apply to the vnode are non-conflicting unless you artificially limit the collision domain to object granularity. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?199901060019.RAA20813>