On Thu, 13 Jun 2002 18:26:54 +0200, Roberto Fichera wrote:
>At 04.58 13/06/02 -0700, David Schwartz wrote:
>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.
You are incorrect. If you have ten threads each waiting for an I/O and all
ten I/Os are ready, then ten context switches are needed. If you have one
thread waiting for ten I/Os, and then I/Os come ready, one context switch is
needed.
[snip]
>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.
I'm not advising eliminating the threads approach. I'm only advising not
using threads as your abstraction for clients or work to be done. Use threads
as the execution vehicles that pick up work when there's work to be done.
(Think thread pools, think separating I/O from computation.)
[snip]
>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,
Even if that's true, and it's often not, how many different types of data
acquisition can you have? Ten? Twenty? That's a far cry from 300.
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:32 EST