Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 5 Jan 1999 13:56:40 -0500 (EST)
From:      Alfred Perlstein <bright@hotjobs.com>
To:        Terry Lambert <tlambert@primenet.com>
Cc:        Wes =?iso-8859-1?Q?Peters=D4?=?=?iso-8859-1?Q?=40=21=EA?=? <wes@softweyr.com>, hackers@FreeBSD.ORG
Subject:   Re: question about re-entrancy.
Message-ID:  <Pine.BSF.4.05.9901051333120.37756-100000@bright.fx.genx.net>
In-Reply-To: <199901051818.LAA08069@usr02.primenet.com>

next in thread | previous in thread | raw e-mail | index | archive | help

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9901051333120.37756-100000>