Messages in this thread | | | Date | Thu, 15 Jul 1999 15:46:52 -0400 | From | Nils Nieuwejaar - Sun High Performance Computing <> | Subject | Re: kernel thread support - LWP's |
| |
On Thu, Jul 15, 1999 at 03:04:23PM -0400, Benjamin LaHaise wrote: > On Thu, 15 Jul 1999, Nate Tuck wrote: > > > In cases where developer time (or time to market) is at a premium and the > > problems at hand require some kind of modular parallelism. I have a > > program on my desk that can run >20 active threads on a one CPU machine. > > Given the problem(s) we had to solve with it, threads saved us many > > man-months of development effort and were the right answer. I can imagine > > that other developers have the same sorts of quandaries (or would if they > > understood how threads could help them). > > I'll agree with you on the cost side of things, but are you certain that > the model used for the application is correct? That is what I'm > questioning, not the fact that your app can trigger >20 active threads. > An event driven system can be worked on by just as many programmers as a > threads based systems.
I don't think the modularity was referring to had anything to do with multiple developers. I expect that he had several independent modules, which could/should execute in parallel, and each of which had some amount of state. By using multiple threads, it is frequently possible to implicitly keep track of this state in a thread's stack.
To switch to an event-based model, that implicit state would have to be explitly saved and restored when processing other events. Depending on the application, that state could be arbitrarily complex, and saving/restoring it could be hard to do quickly and correctly. Once you've written all the save/restore code, you've essentially written your own special-purpose user-level threading library, and each 'event' is really just a 'context switch'.
- 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/
| |