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

[Leon Woestenberg]

Hello,

On Mon, Apr 6, 2009 at 1:38 PM, Jason Garrett-Glaser
<darkshikari at gmail.com> wrote:
> On Mon, Apr 6, 2009 at 2:33 AM, Gabriel Bouvigne
> <gabriel.bouvigne at joost.com> wrote:
>> Mike Kazmier a écrit :
>>>
>>> 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.
>
Indeed, the impact should be neglectible for this application of
condition variables. What is the approximate frequency of
cond_signal() being called?

Was the signaling thread falsely signaling the condition and thus the
cond_wait thread looping over pthread_cond_wait() or is the waiting
thread performing a too-strict conditional after cond_wait() falls
through?

*sleep() in an application? Yuk. Event-driven all the way please.

Regards,
-- 
Leon