[x264-devel] Updated (and hopefully final) threaded slicetype patch

[David DeHaven]

>>>
>>> I said these should be replaced with cond_wait, but this made the
>>> patch much much slower, which makes me suspect it's waiting when it
>>> shouldn't; the overhead of pthreads should be minimal.
>>
>> What about pthread conditions is minimal? In some cases (e.g. Mac OS
>> X) you're forcing a context switch into the kernel to perform the
>> signaling. Also, when you give up processor time to another thread by
>> blocking thread execution (rather than spinning) you're committing
>> yourself to NOT get any CPU time at least for the next time slice
>> duration which on a lot of systems can be pretty significant.
>
> Do any modern systems still have timeslices in the classical sense?

Yes.

Here's a decent article on the Linux 2.6 scheduler:
http://www.ibm.com/developerworks/linux/library/l-scheduler/

Notice one of the first thing he says: "An important goal of a  
scheduler is to allocate CPU time slices ..."

-DrD-