From owner-freebsd-hackers Tue Jan 5 15:32:59 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA01667 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 15:32:59 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA01662 for ; Tue, 5 Jan 1999 15:32:58 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id PAA98527; Tue, 5 Jan 1999 15:32:29 -0800 (PST) (envelope-from dillon) Date: Tue, 5 Jan 1999 15:32:29 -0800 (PST) From: Matthew Dillon Message-Id: <199901052332.PAA98527@apollo.backplane.com> To: Alfred Perlstein Cc: Terry Lambert , wes@softweyr.com, hackers@FreeBSD.ORG Subject: Re: question about re-entrancy. References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> :> So if you a section of code that does this (each letter designates a :> fine granularity lock surrounding a section of code): :> :> A B C D E :> :> A B C A D E :> : :this would allow you to define let's say several oprations to be done on :processes, in a somewhat OOP manner. : :Instead of having one lock on each process struct, you can orginize it so :that a module of functions lock against each other in such a way that: I should be more specific: The pipeline rule applies both to structural locks and code space locks. All that matters, really, is that you *NOT* break the pipeline rule. You want to try to make the granularity of the locks around the same in the *time* domain (time spent with lock held). This concept is also unrelated to whether you use a code space lock or a structural lock. Once you are sure you are following the pipelining rule, *THEN* you can try to optimize the parallism by using either code space or structural locks, depending on the situation. :thinking more about it, it seems that you would have a read-modify-write :problem where an object lock is nessesary, this leads me to think i'm not :thinking about this correctly... : :also the concept of having data move out from under a local pointer :becasue of another CPU thread boggles me a bit. : :-Alfred Generally speaking you do not want to use multi-valued locks for SMP operations. i.e. the concept of a 'shared' lock verses an 'exclusive' lock does not work well for locks used to manage SMP functions. The reason it doesn't work well is because of truely serious starvation issues -- it is virtually always more efficient for the fine-grained SMP locks as *only* exclusive locks and then work on optimizing the pipelines. course-grained locks should typically *not* be SMP locks but instead be structural locks with real blocking (the 'go to sleep' type of blocking). The exception, of course, is the One-Big-Lock model: the model is really just a big hack so the normal rules do not apply to it. -Matt Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message