[x264-devel] Re: bug in commit 607

[Marco Gaddoni]

Hello,

Måns Rullgård wrote:
> 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.
>   
mmm, the call to usleep could clobber *foo if foo is global so the 
compiler cannot
avoid to reload *foo.
moreover, all the caches in usable systems are coherent and reflect the 
state of the other cpus.
so, provided that usleep is not inlined and foo is somewhat global i 
think this kind
of synconization should work.
I agree with you that a mutex or a condition variable is better.


Ciao

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