[x264-devel] Re: bug in commit 607

[Måns Rullgård]

Loren Merritt <lorenm at u.washington.edu> writes:

> On Sat, 16 Dec 2006, Måns Rullgård wrote:
>>
>> The problem is with the pthread stuff at line 48 and following in
>> common/common.h, specifically the #define pthread_t int and similar
>> lines.  This whole chunk looks very dodgy to me.  Redefining system
>> symbols is never a good idea.
>>
>> Loren, what's the deal with this?  What's the purpose of the
>> USE_CONDITION_VAR thing, and why is it only defined on windows?
>
> On linux, we don't need any thread synchronization primitives.
>    while(!*foo) usleep(100);

That is not guaranteed to work.  The compiler is free to optimize out
all but the first test of the condition, and even if the compiler does
not, the CPU might cache the value.  Using a mutex enforces the
necessary barriers to make it safe.

> is faster (though not by much. it wouldn't kill performance if we had
> to enable condition variables on linux too).

How much of a difference does it make?

> But on windows, that is very slow and can even hang. win32's own
> WaitForSingleObject was also slow, though more stable.
>
>> Instead of #defining pthread_t and friends, typedefing x264_thread_t
>> etc depending on the system should be safer.
>
> Yes, that's an acceptable alternative.

I'll have look at it.

-- 
Måns Rullgård
mru at inprovide.com

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html