Subj : Re: Threading strategy To : comp.programming.threads From : Sean Burke Date : Thu Apr 07 2005 07:52 pm "ajay kumar" writes: > >From your description it looks like that the subsystems of yours can > handle only one unit at a time, which implies the performance of these > subsystems decide the overall performance of this machine. > > I think having one thread per Unit wouldn't have any positive impact on > the performance as the subsytems play the bottleneck. If functioning of > subsystems is in your control you may possibly try to make them > premptible, I mean, if a subsytem finds that it cannot continue with a > unit, pauses it, stalls the unit somewhere, continues with next unit > and then resumes later with the paused unit when it can do so. > > If the rate of unit production is lower than the average rate of > handling of a unit by the system as a whole, any approach looks as good > as the other and you can go ahead whichever you feel simple. > > If I have to choose one design to work in any generic case, I would go > for the second approach. > > BTW, I have no hands on experience with any such situation. These are > just some intutive ideas I had. A producer-consumer system linked by queues (thread-per-subsystem) has the advantage that the queues enable you to limit the number of buffered work units, thereby governing your overall throughput to that of the slowest subsystem. In the thread-per-work-unit approach, you must supply some sort of feedback mechanism to govern the rate at which new work units are inititiated, unless you are certain that this cannot exceed the system's long-term throughput. -SEan .