>Depending by the applications. With my simulation/emulation program I need
>to create
>many thread because each thread resolve/manage/compute a specific problem
and
>it's live depend by some factors. Each thread is create only if needed to
>avoid the
>overhead. The simulation/emulation is a "merge" of many and many object,
>each object
>work to resolve/manage/compute a specific problem. All the low objects are
>grouped to
>resolve a specific problem and are managed by a thread controller that
>should take some
>decision or doing some work. Some thread controller are grouped and managed
>by another
>thread controller and so on. Do not think that I need always 400 threads
>active they are
>create only if need by the controller. You must thinks this
>simulation/emulation as collection
>of many and many object that should interoperate, and the model is designed
>to scale easily
>on a distribuite environment.
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).
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.
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').
DS
-
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/
This archive was generated by hypermail 2b29 : Sat Jun 15 2002 - 22:00:28 EST