Messages in this thread | | | Date | Thu, 13 Jun 2002 13:21:54 +0200 | From | Roberto Fichera <> | Subject | Re: Developing multi-threading applications |
| |
At 03.13 13/06/02 -0700, you wrote:
>On Thu, 13 Jun 2002 11:08:27 +0200, Roberto Fichera wrote: > >You are right! But "computational intensive" is not totaly right as I say ;- > >), > > It's really not fair to change the premises in the middle of an > argument.
Sorry ;-)!
> >because most of thread are waiting for I/O, > > Still wrong. You don't tie up threads waiting for I/O. You can > wait without >having a thread doing the waiting. > > >after I/O are performed the > >computational intensive tasks, finished its work all the result are sent > >to thread-father, > > Okay, so you need a new abstraction -- separate the waiting from the >working. Create as many threads to do the work as you have processors to do >the work on. As for the waiting, minimize threads waiting, they're pure >overhead. If it's sockets, use 'poll' so one thread can do lots of waiting.
This's a possible solution.
> >the father collect all the child's result and perform some > >computational work and send its result to its father and so on with many > >thread-father controlling other child. So I think the main problem/overhead > >is thread creation and the thread's numbers. > > So get rid of the problem! Don't create so many threads, create > only as many >threads as can do useful work and reuse them rather than destroying and >recreating them. Solve the actual problem/overhead since it's totally >artificial and due to your model rather than your problem!
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.
> DS
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/
| |