At Tue, 20 Feb 2007 19:37:47 -0800,
Bucky Katz wrote:
> 
> Anytime the library level scheduler can bypass a trip to the kernel
> because it can do a switch the overhead of the kernel trap is
> saved. The more threads you use, especially the more that synchronize,
> the more likely you are to find one thread about to sleep on some kind
> of even while you've got another one runable.  The finer grained your
> use of thread synchronization is, the worse the problem becomes -- and
> that's actually true independent of the architecture, so long as a
> kernel trap is more expensive than a procedure call.

Ah ha!!!  That's what I thought you were _really_ talking about all
along, but somehow it was never said in any way that was clear enough
for me to grasp.  :-)

So, what you are really asking for is N:1 threading, _not_ M:N,
especially since you're really only talking about uniprocessor kernels
here too.

There is, as I understand it (and I may be mistaken), a huge difference.

I suppose the question to be answered before newlock2 hits a release
branch is whether or not the specific case of having a special UP N:1
libpthread implementation is useful and beneficial enough to forgo
trying to get the more general case of a MP/UP M:N libpthread working
with newlock2, or not.

-- 
						Greg A. Woods

H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>       Secrets of the Weird <woods@weird.com>