Messages in this thread | | | From | "David Schwartz" <> | Subject | RE: RasterMan on linux and threads | Date | Sat, 18 Dec 1999 13:17:24 -0800 |
| |
> There still is the issue of cache flushing > though. Keeping the threads on their own > CPU does not alleviate the program of pushing > the data from one thread back to the other > (or from one CPU to the other). > > Rik
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/
| |