Messages in this thread | | | Date | Thu, 13 Jun 2002 18:26:54 +0200 | From | Roberto Fichera <> | Subject | Re: Developing multi-threading applications |
| |
At 04.58 13/06/02 -0700, David Schwartz wrote:
> If it's a simulation, you don't *really* need the threads, you > just need to >be able to act as if you had them. After all, what are you simulating if what >work gets done when is up to the random vagaries of the OS scheduler? > > If it's a real application wanting real performance, the > suggestions I made >stand -- you don't want many more threads working than you have CPUs and you >don't want a lot of threads sitting around waiting for work (and thus forcing >bazillions of extra context switches).
This is a scheduler problem! All threads waiting for I/O are blocked by the scheduler, and this doesn't have any impact for the context switches it increase only the waitqueue, using the Ingo's O(1) scheduler, a big piece of code, it should make a big difference for example.
> It sounds to me like your design is broken, needlessly mapping > threads to >I/Os that are being waited for one-to-one. This is a common error among >programmers who consciously or subconsciously have accepted the 'more threads >can do more work' philosophy.
I don't think "more threads == more work done"! With the thread's approch it's possible to split a big sequential program in a variety of concurrent logical programs with a big win for code revisions and new implementation.
> What you need to do is take whatever it is you're thinking of as > a 'thread' >right now, which I'd roughly define as 'one logical task, from start to >completion' and realize that there is absolutely no reason to map this >one-to-one to actual pthreads threads and every reason in the world not to. > > This will conserve resources (12 thread stacks instead of 300, 12 > KSEs >instead of 300), reduce context switches (context switches will only occur >when there's no work to do at all or a thread uses up its entire timeslice >rather than every time we change which client/task we're doing work for/on), >improve scheduler efficiency (because the number of ready threads will not >exceed the number of CPUs by much) and more often than not, clean up a lot of >ugliness in your architecture (because threads are probably being used >instead of a sane abstraction for 'work to be done' or 'a client I'm doing >work for').
You are right! But depend by the application! If you have todo I/O like signal acquisition, sensors acquisitions and so on, you must have a one thread for each type of data acquisition, you must have a thread that perform some data computation with a subset, for examples, of this data, and generate the output that could be a new input for an other thread. This make the environment more realistic. I agree with you that if we increase the thread's numbers the system could collapse (= context switches become expensive = we must increase the CPU numbers or new box is required or new approch should be make).
Roberto Fichera.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |