Date: Tue, 5 Jan 1999 15:32:29 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Alfred Perlstein <bright@hotjobs.com> Cc: Terry Lambert <tlambert@primenet.com>, wes@softweyr.com, hackers@FreeBSD.ORG Subject: Re: question about re-entrancy. Message-ID: <199901052332.PAA98527@apollo.backplane.com> References: <Pine.BSF.4.05.9901051814120.37756-100000@bright.fx.genx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
:>
:> 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
:>
:<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:
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.
<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?199901052332.PAA98527>