Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 05 Jan 1999 17:00:23 -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:  <3692A797.975E8433@softweyr.com>
References:  <199901052008.NAA09332@mt.sri.com> <199901052245.PAA24981@usr02.primenet.com> <199901052249.PAA10421@mt.sri.com> <3692A39C.889BF032@softweyr.com> <199901052348.QAA10896@mt.sri.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Nate Williams wrote:
> 
> > 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.
> 
> 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. ;(

I guess your "resource manager" *is* my "parallel waiting system."  I've
only looked at this in a deeply embedded context, where the 3 processors
share a single coherent cache and transaction-oriented memory bus, so my 
experience may not be completely scalable.  I should add that it's not 
working yet either.  ;^)

The working idea is that if I have acquired a lock on one of a set of
objects, but not all of the objects (therefore I'm sleeping), a higher
priority task can 'steal back' an object from me.  While quite flexible,
it requires *very careful attention* to priorities, and opens up avenues
to deadlocks that boggle the mind.  In our particular application, it
is quite a neat little trick, where we have three processors and what
amounts to seven input queues and seven output queues, and need to route
data between 1..7 of the queues at a time.

-- 
             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?3692A797.975E8433>