Messages in this thread |  | | Date | Sat, 2 Sep 2000 00:48:31 -0700 (PDT) | From | dean gaudet <> | Subject | Re: thread rant |
| |
On Fri, 1 Sep 2000, Mike A. Harris wrote:
> I've heard comments from Alan, and others in the past bashing > threads, and I can understand the "threads are for people who > can't write state machines" comments I've heard, but what other > ways are there of accomplishing the goals that threads solve in > an acceptable manner that gives good performance without coding > complexity?
the thread bashing is mostly bashing programs which do things such as a thread per-connection. this is the most obvious, and easy way to use threads, but it's not necessarily the best performance, and certainly doesn't scale. (on the scalability side just ask yourself how much RAM is consumed by stacks -- how many cache lines will that consume, and how many TLB entries. it sucks pretty fast.)
state machines are hard. while people on linux-kernel may be hot shot programmers who can do state machines in their sleep, this is definitely not the case for the average programmer.
fortunately fully threaded and fully state driven are two opposite ends of a spectrum, and there are lots of useful compromises in between where threads are used in a way that allows the average programmer to maintain/extend a codebase; while also getting the scalability of state machines.
this is where "worker thread pools" and message queues come in.
for example, consider an IMAP server. the fully threaded implementation would have a thread per connection. but most connections sit idle most of the time. instead restructure it so that there is a thread per in-progress command; plus one thread doing a state machine for all the idle connections. this scales much better because you only have as many threads as active commands. the actual IMAP code itself can be written in the comfortable threading model rather than a state model.
it's still not perfect -- large mail messages sent to slow clients chew a thread for an inordinate amount of time. an obvious next modification would be to let the state thread also handle the sending of messages. this can be done relatively cleanly.
part of the apache-2.0 design was to allow for such a setup -- using a thread for the "thinking" part of each HTTP request, and once a response object is decided on, it is passed back to the state machine. (responses generally fit into the categories of disk file, pipe, or memory region.) but nobody has yet implemented beyond thread-per-connection.
-dean
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |