Date: Tue, 5 Jan 1999 18:26:35 -0500 (EST) From: Alfred Perlstein <bright@hotjobs.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Terry Lambert <tlambert@primenet.com>, wes@softweyr.com, hackers@FreeBSD.ORG Subject: Re: question about re-entrancy. Message-ID: <Pine.BSF.4.05.9901051814120.37756-100000@bright.fx.genx.net> In-Reply-To: <199901052303.PAA98165@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. <question> 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. > <dillon@backplane.com> (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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9901051814120.37756-100000>