Interesting analysis of linux kernel threading by IBM

[David Wragg]

Alan Cox <alan en lxorguk.ukuu.org.uk> writes:
> > the IBM paper), that if your application depends on huge numbers of
> > threads, you're always going to keep bumping up against the scheduler?
> > a lot of people throw lots of threads at a problem and it can really
> > be bad design.
> 
> That is the least of your worry. 1000 threads is 8Mb of kernel stacks, and 
> enough switching of tasks to be sure you might as well turn most of your 
> cache off. A computer is a state machine.

But the number of possible states in a computer is quite big.

(How many bits of memory does your machine have? What about including
the other machines on the network?)

> Threads are for people who cant
> program state machines.

Lots of people want to program state machines. But their languages
don't offer them ways to express interacting state machines properly;
instead they get sold short-term partial solutions like threads and
objects.

Take two interacting state machines. Individually, they have a small
number of states, and you can reason about them without getting a
headache. Now take the state machine formed by composing them, and
forgetting the internal structure. In general, the number of states of
this combination is greater (typically much greater) than the sum of
the numbers of states of the individual machines, and reasoning about
it becomes correspondingly more difficult.

So decomposition is good. Procedural decomposition is familiar to C
programmers. But C has no facilities for expressing concurrency. Some
languages have been designed with threads in mind, but their
facilities for concurrency tend not to be compositional in nature, so
they don't actually work very well.

If properly expressed, threads == state machines == event driven ==
asynchronous I/O.

Given languages to express concurrency neatly, implementing them is
another interesting problem. Kernel threads are likely to be the wrong
approach, except as a mechanism to keep multiple processors occupied
and to get concurrent disk I/O.


David Wragg


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo en vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/