From owner-freebsd-hackers Tue Jan 5 15:23:01 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA29825 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 15:23:01 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bright.fx.genx.net (bright.fx.genx.net [206.64.4.154]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA29819 for ; Tue, 5 Jan 1999 15:22:57 -0800 (PST) (envelope-from bright@hotjobs.com) Received: from localhost (bright@localhost) by bright.fx.genx.net (8.9.1/8.9.1) with ESMTP id SAA50320; Tue, 5 Jan 1999 18:26:35 -0500 (EST) (envelope-from bright@hotjobs.com) X-Authentication-Warning: bright.fx.genx.net: bright owned process doing -bs Date: Tue, 5 Jan 1999 18:26:35 -0500 (EST) From: Alfred Perlstein X-Sender: bright@bright.fx.genx.net To: Matthew Dillon cc: Terry Lambert , wes@softweyr.com, hackers@FreeBSD.ORG Subject: Re: question about re-entrancy. In-Reply-To: <199901052303.PAA98165@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 5 Jan 1999, Matthew Dillon wrote: > This is a really good analogy, with one change: The problem with > the red zones is not so much that only one spider can go through > it at a time, but of the pipelining that is achievable when you > have to go through a red zone. The inability to pipeline inherently > limits the number of processors you can run through the code > 'simultaniously'... as long as you do not stall the pipeline, > you are ok. > > 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 > > You can usually assume infinite scaleability (even though it isn't > really infinite). While it is true that one processor will stall for > a short period when two try to get A, this tends to have a synchronizing > effect so the NEXT time the two processors call A, they will tend to do > it pre-synchronized and neither will stall (or they will not stall as > long). > > The actual 'virtual' size of the pipeline depends on how various > subsystems within the kernel interact with each other. > > The main design rule you want to follow to minimize the impact of > the locks is to avoid 'loops' in the pipeline. A loop --- like the > lock sequence: > > A B C A D E > > In which A loops, creates a major stall situation. If you follow > the pipelining rule, you generally do not have to worry about the > scaleability of fine-granularity locks. 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: functions that may munge pointers can't be in use at the same time as functions that change information in the record can not be in use at the same time as functions that return information in the record i'm unsure of the optimal way to orginize this, or if i'm totally off base anyway. 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 > > -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