Re: Developing multi-threading applications

[David Schwartz <davids@webmaster.com>]

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