From owner-freebsd-hackers Tue Jan 5 15:52:47 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA04457 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 15:52:47 -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 PAA04408 for ; Tue, 5 Jan 1999 15:52:40 -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 SAA50359; Tue, 5 Jan 1999 18:56:19 -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:56:19 -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: <199901052332.PAA98527@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: > :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. > (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