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>