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.
>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.
>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!
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