Subj : Re: Threading strategy
To   : comp.programming.threads
From : Eric Sosman
Date : Thu Apr 07 2005 04:35 pm



b.fokke@gmail.com wrote:
> Hi,
> 
> I'm writing process operating software and I have a question regarding
> Multi threading strategy. The machine has a couple of subsystems. The
> machine produces units, which have to pass these subsystems in
> sequential order. Since the time each subsystem takes to complete its
> job varies, there are buffers between the subsystems.
> 
> Basically there are two different approaches:
> 
> - Use one thread per unit. The code would look something like this:
> [...]
> - The other approach is to use one thread per subsystem. Each subsystem
> thread would look something like this:
> [...]

    At the risk of having the experts berate my foolishness
(in parallel, of course), I think there's an approach you
haven't considered: Run as many threads as can profitably
use the computing resources at hand.  This requires that you
decouple the threads from the components of the model --
product units, work stations, whatever -- and use them instead
as anonymous execution agents in the manner of the popular
"thread pool" architecture.

    The drawback is that each model component must maintain
its state independently of whether it happens to be executing
on a thread at the moment -- in short, it can no longer use
the program counter as part of its persistent state -- and
maintaining state explicitly usually requires code (although
it's code that the Object-Oriented Orthodoxy will say should
have been there anyhow).  The advantage is that you can adjust
the thread count to the size of the computer rather than to
the size of the problem, and this often gives a considerable
gain in flexibility and scalability.

-- 
Eric.Sosman@sun.com

.