user-space threads

[Adam Megacz]

"Boehm, Hans" <hans_boehm@hp.com> writes:
> I understand it is claimed to solve the 10K thread problem.)

How do they get around the L1/TLB cache thrash problem of having the
"working set" be 10,000 seperate memory pages, each with its own page
table entry (since the page above the stack must be write-protected)?

I propose to solve this with stack-sharing.


> I would be opposed to making a user-level threads package the
> default on any system that had another, more standard threads
> implementation,

Agreed.  I'm definately not suggesting this as the default.  However,
it could make multithreaded servers as fast as nonblocking-io,
singlethread servers.  The big advantage is that the multithreaded
paridigm is far easier to write code for.


> I'm not sure how far you can really reduce maximum thread stack
> sizes,

I don't propose to decrease the total amount of stack used, but I do
propose to coagulate it all onto a single, contiguous set of pages in
order to maximize L1 and TLB cache effectiveness.  This is widely
believed to be the biggest reason why high-performance thread
implementations are still slower than select()-based single-threaded
servers.


  - a

-- 
"Through your rags I see your vanity"  -- Socrates