Date: Tue, 5 Jan 1999 18:56:19 -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.9901051838400.37756-100000@bright.fx.genx.net> In-Reply-To: <199901052332.PAA98527@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 5 Jan 1999, Matthew Dillon wrote: > :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. You may have misunderstood me, several threads could enter a 'read' state, when a 'write' must occur no more threads are allowed into the 'read' state until the 'write' state is complete. All the readers have to drain out of their code before a write can take place. Or is this exactly what you are objecting to? > 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. Well yes, ala SunOS 4.x.x :) -Alfred -who's finding -current a better source of knowledge than his short college stint :) thanks for the patience and explanations. > > -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.9901051838400.37756-100000>