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

[David DeHaven]

>>> 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. Most  
implementations of usleep/nanosleep that I've looked at will simply  
spin if the value is low enough (due to the overhead of context  
switching and having to defer to the kernel), which might explain why  
it performs better than using pthread conditions.

Does the timeout on select() have the same resolution as Sleep()?  
Maybe that could be used under MinGW instead.

-DrD-