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

[Måns Rullgård]

David DeHaven <dave at sagetv.com> writes:

>>>> Please find version 13 (lucky # 13) of the threaded slicetype
>>>> patch.  This
>>>> patch is overhauled to be more "windows" friendly (read: no use of
>>>> usleep)
>>>> and strictly use pthread_cond_wait/broadcast.
>>>
>>> Could you please explain why a simple
>>> #define usleep(t) Sleep((t)/1000)
>>> would not be work? Is it because you need more than a millisecond of
>>> accuracy?
>>
>> The patch used to use spin loops for synchronization, e.g:
>>
>> while(condition isn't true)
>> {
>> usleep(100);
>> }
>>
>> 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?

-- 
Måns Rullgård
mans at mansr.com