From owner-freebsd-hackers Tue Jan 5 16:02:40 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA07138 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 16:02:40 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA07124 for ; Tue, 5 Jan 1999 16:02:37 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id QAA11587; Tue, 5 Jan 1999 16:00:27 -0800 (PST) Received: from utah.XYLAN.COM by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id QAA02468; Tue, 5 Jan 1999 16:00:25 -0800 Received: from softweyr.com by utah.XYLAN.COM (SMI-8.6/SMI-SVR4 (xylan utah [SPOOL])) id RAA13793; Tue, 5 Jan 1999 17:00:23 -0700 Message-ID: <3692A797.975E8433@softweyr.com> Date: Tue, 05 Jan 1999 17:00:23 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 2.2.7-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Nate Williams CC: Terry Lambert , narvi@haldjas.folklore.ee, bright@hotjobs.com, hackers@FreeBSD.ORG Subject: Re: question about re-entrancy. 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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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