From owner-freebsd-hackers Tue Jan 5 10:53:00 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA19668 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 10:53:00 -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 KAA19657 for ; Tue, 5 Jan 1999 10:52:59 -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 NAA49947; Tue, 5 Jan 1999 13:56:40 -0500 (EST) (envelope-from bright@hotjobs.com) X-Authentication-Warning: bright.fx.genx.net: bright owned process doing -bs Date: Tue, 5 Jan 1999 13:56:40 -0500 (EST) From: Alfred Perlstein X-Sender: bright@bright.fx.genx.net To: Terry Lambert cc: Wes =?iso-8859-1?Q?Peters=D4?=?=?iso-8859-1?Q?=40=21=EA?=? , hackers@FreeBSD.ORG Subject: Re: question about re-entrancy. In-Reply-To: <199901051818.LAA08069@usr02.primenet.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, Terry Lambert wrote: > 3) Object locks are the wrong way to address the reentrancy > issue. The problem with object locks is that it puts > objects that don't really need to be in a contention > domain into one in order to satisfy contention in what > are usually very small critical sections having to do > with list manipulation of pointers to the object. This > type of thinking is why most Intel based SMP OS's claim > that scaling past 4 processors is "useless". What they > really mean is that their SMP OS is useless for more > than 4 processors. Yeah, you have to have *some* object > locks for non-reentrant objects (e.g., the I/O bus), but > this is pretty much limited to physical hardware limits, > and isn't really applicable for, for instance, vnodes. Would it work if you had a thread per processor that allows requests for object manipulation to be put into a queue? You could queue requests to remove items from a list, and to allocate new ones. then you can keep a lock on the individual objects and not the entire list. Excuse niaveness, I haven't done anything in this area, I just love thinking about it. -Alfred > > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message