Date: Tue, 5 Jan 1999 16:48:20 -0700 From: Nate Williams <nate@mt.sri.com> To: Wes Peters <wes@softweyr.com> Cc: Nate Williams <nate@mt.sri.com>, Terry Lambert <tlambert@primenet.com>, narvi@haldjas.folklore.ee, bright@hotjobs.com, hackers@FreeBSD.ORG Subject: Re: question about re-entrancy. Message-ID: <199901052348.QAA10896@mt.sri.com> In-Reply-To: <3692A39C.889BF032@softweyr.com> References: <199901052008.NAA09332@mt.sri.com> <199901052245.PAA24981@usr02.primenet.com> <199901052249.PAA10421@mt.sri.com> <3692A39C.889BF032@softweyr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > > The third way (about which Terry did talk) is to have locks around > > > > > critical sections. > > > > > > > > That *is* what an 'object lock' in RTEMS is. > > > > > > No. An object lock is associated with an object. A critical section > > > lock is associated with a section of code. > > > > An object lock can be associated with a lock that does nothing but > > associate itself with a critical section. > > This type of object is generally known as a "semaphore." Right, I mentioned this in an early article. > > *sheesh* This ain't rocket science. > > No, and the problems Terry brings up are real, but only because designers > have made them real. One of the biggest problems with object-locking > systems is the serial acquisition of locks. Say for instance I want to > transfer some data from one device to another, and I don't want to add > the overhead of buffering it in memory. I acquire the read-lock on the > first device, then acquire the write-lock on the second. Once both locks > have been acquired, I can transfer the data and release the locks. Can you say potential 'deadlock'? I knew you could. :) > The problem with this model, which is commonly used, is that I hold the > read-lock on the first device while waiting to acquire the write-lock > on the second, or vice versa. A parallel waiting system, in which another > potential reader of the first device can "take away" my lock if I'm still > pending for another resource, alleviates this problem. You have to avoid > priority problems when doing this, but inherited priorities are a pretty > well understood solution to this problem. Right. So how else do you solve the problem of 'protecting' critical sections? I don't see how else to protect them other than using 'object locks' (however you want to call them). If you have multiple shared resources, you still need to get access to them. One of the more common ways I've seen this done is through a 'resource manager' inside of the kernel which guarantees that you 'lock down' the resources in exactly the same order. Unfortunately, this tends to be a bottleneck on highly parallel systems. ;( 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?199901052348.QAA10896>