Date: Tue, 05 Jan 1999 16:43:24 -0700 From: Wes Peters <wes@softweyr.com> To: Nate Williams <nate@mt.sri.com> Cc: Terry Lambert <tlambert@primenet.com>, narvi@haldjas.folklore.ee, bright@hotjobs.com, hackers@FreeBSD.ORG Subject: Re: question about re-entrancy. Message-ID: <3692A39C.889BF032@softweyr.com> References: <199901052008.NAA09332@mt.sri.com> <199901052245.PAA24981@usr02.primenet.com> <199901052249.PAA10421@mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Nate Williams wrote: > > > > > 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." > *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. 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. -- Where am I, and what am I doing in this handbasket? Wes Peters +1.801.915.2061 Softweyr LLC wes@softweyr.com 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?3692A39C.889BF032>