[XviD-devel] mulithread rework

[Edouard Gomez]

Quoting Con Kolivas <kernel at kolivas.org>:
> Converting it to strict locking has the effect of performing at
> virtually the same rate of frame encoding, but with much less CPU
> usage.

Did you just remove the "spinlocking" around the sched_yield or did
you turn that wait code to pthread_condition stuff ?

Yesterday i wrote an email from home proposing the use of a thread pool
but the email didn't get through the mailing list agent.

Because as I see it, the current thread implementation is suboptimal because
threads are waiting actively on single tasks (next above block is completed).
With a thread pool and a task queue, it is then possible to queue up more tasks
and then let the consumers start picking from it.


> So are there any other potential gains? There are minor improvements
> to actual FPS encoded if all the threads are generated in advance and
> not generated/destroyed on each frame being encoded because thread
> creation is not exactly instantaneous, and allows CPU balancing to
> move them around in advance rather than always starting on the same
> CPU as the parent process. However, even this does not amount to much
> improvement (I can't give you a firm figure but eyeballing the FPS was
> not impressive).

Yeah that was my idea with the threadpools, thread creation cost is
reduced to a minimum.

If it can help you investigate the threading pool + task queue, i have some
free code online that can serve as a good starting point.

See:
http://ed.gomez.free.fr/vrac/threadpool.c
http://ed.gomez.free.fr/vrac/threadpool.h

The API is quite easy to understand, but be aware that the flush operation
doesn't sync on thread task completion, it just makes sure the task queue is
empty before returning. It's a 5min exercice (left to the reader) to add
a sync on tasks completion instead.

-- 
Edouard Gomez