Right. This means that people who design multi-threaded programs have to be
smart enough to prevent this from being a problem. It may be a losing
proposition to try to split parts of a single request across threads if they
share too much state information. Especially if one thread will be changing
state information another thread is using. On the other hand, it may make
very good sense to distribute different requests to different threads.
It's very difficult to make a library that does one small computation very
quickly by using multiple threads. If it had to do it with no outside
cooperation, it would have to create the threads, assign a small task to
them, and then wait for them all to complete. Odds are, this would take
longer than just having one CPU do the job.
On the other hand, if you have to do the same expensive operation on
different data sets, that may parallelize very well. You have to know when
and how to use threads. And the rules are very different for a web server
(where each request is relatively low-cost and independant) than they are
for an SQL database (where individual requests may be worth splitting and
shared state changes), for example.
DS
-
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/