[XviD-devel] mulithread rework

[Edouard Gomez]

Radek Czyz (radoslaw at syskin.cjb.net) wrote:
> Yes, updating own complete_count_self (which means updating someone 
> else's complete_count_above) can be changed to a proper signal for that 
> thread below to continue.

The whole thing could be replaced with a much cleaner thread pool
implementation. A consumer would push new bunches of available blocks
to the work queue and let the pool consumers pop them from the queue
when they are ready to process new data.

That would avoid all that "spinlocking" on the complete_count_above
vars. But that means using conditions and mutexes to guarantee the
queue thread safety. So in the end you add OS work which can cost
a lot.

The thread pool doesn't require spawning threads at each FrameCodeP
or FrameCodeB.

So to make the threadpool worth using, you have to ensure that
the cost of the thread queue synchronisation is <<< compared to the
task unit of each consumer.