Brian Hurt wrote:
> Thousands of threads in a program is not unreasonable. If you may want to
> take full advantage of a 128 CPU machine, for example, you need _at_
> _least_ 128 threads.
You want exactly 128 threads running, no more.
> If your threads spend most of their time blocking,
> you need even more threads, you need to overschedule, to make sure you
> generally have enough threads not blocking to make sure CPUs aren't going
> to waste.
You want threads that block to active new threads so there are still
exactly 128 running at a time.
> User level threads are not a full solution- they help, and are a good
> thing, but are not a silver bullet. The basic problem is that there are
> still ways for a process to block that can't be intercepted and "faked" by
> the user level threads- page faulting, for instance. And if a thread
> blocks, all threads that share that process are also blocked. Plus, all
> the problems and difficulties of scheduling are not removed, they're
> simply shoved onto the threading library.
That's all solved by having blocking threads activate another thread to
fill in the gap, and something to do the same in the reverse. But
no-one's written the code yet.
enjoy,
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jan 23 2000 - 21:00:27 EST