user-space threads

[Adam Megacz]

"Boehm, Hans" <hans_boehm@hp.com> writes:
> since a cache line will be smaller than the active part of each
> thread stack anyway.

> I think TLB miss handling times are generally considerably less than
> context-switch times.

Two good points.  Perhaps cache/tlb thrash isn't the reason threads
are slower.


> I would have guessed there are other significant differences.  On
> the negative side, "Context switches" are cheaper in the select
> case.

Are they?  IIRC three things can cause a context switch:

1) Timer interrupt.  This averages out in the long run, since the time
   to process a timer interrupt is usually only a tiny fraction of the
   scheduling quantum.

2) Blocking I/O.  In this case, a context switch with user threads
   should be no slower than a procedure call, since the caller has
   already saved whatever register state they need.

3) Thread death.  No state to save.

So I can't see why this would degrade performance.  Hrm.


> Explicit state is probably much more compact than a thread stack and
> thread descriptor.

I can see why this would make multithreaded servers consume more
memory than select() servers, but with 1GB of memory for $123 you
should be able to fit at least 10,000 thread stacks even if each stack
is 100kb in size (which is highly unlikely, especially in Java!).

I'm really interested in getting to the bottom of this... right now
I'm studying systems at Berkeley, and they're really pushing things in
the direction of select() based servers (see Matt Welsh's SEDA paper),
but the funny thing is that they *don't know why they're doing it*.
I'd love to come up with a threading implementation that proves them
wrong.

  - a

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