Re: Developing multi-threading applications

From: Peter Wächtler (
Date: Thu Jun 13 2002 - 04:44:33 EST

Roberto Fichera wrote:
> At 01.26 13/06/02 -0700, you wrote:
>> On Thu, 13 Jun 2002 10:13:35 +0200, Roberto Fichera wrote:
>> >I'm designing a multithreding application with many threads,
>> >from ~100 to 300/400. I need to take some decisions about
>> >which threading library use, and which patch I need for the
>> >kernel to improve the scheduler performances. The machines
>> >will be a SMP Xeon with 4/8 processors with 4Gb RAM.
>> >All threads are almost computational intensive and the library
>> >need a fast interprocess comunication and syncronization
>> >because there are many sync & async threads time
>> >dependent and/or critical. I'm planning, in the future, to distribuite
>> >all the threads in a pool of SMP box.
>> With 4/8 processors, you don't want to create 100-400 threads
>> doing
>> computation intensive tasks. So redesign things so that the number of
>> threads
>> you create is more in line with the number of CPUs you have available.
>> That
>> is, use a 'thread per CPU' (or slightly more threads than their are
>> CPUs per
>> node) approach and you'll perform a lot better. Distribute the
>> available work
>> over the available threads.
> You are right! But "computational intensive" is not totaly right as I
> say ;-),
> because most of thread are waiting for I/O, after I/O are performed the
> computational intensive tasks, finished its work all the result are sent
> to thread-father, 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.

Have a look at

they provide M:N threading model where threads can live in userspace.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Sat Jun 15 2002 - 22:00:28 EST