[x264-devel] Re: bug in commit 607

[Jon Schlueter]

On 12/18/06, Loren Merritt <lorenm at u.washington.edu> wrote:
> On Sun, 17 Dec 2006, 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
>
> Ok, but the fix for that would be volatile. I don't see what a function
> call to pthread_mutex_lock has to do with it, unless any function call
> would be sufficient since the compiler has to assume that any function
> might modify that memory address.

In order to assure that you don't have race conditions and your
threading is correct you basically need to use the threading library
lock and unlock.... see

Scott Meyers
http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf

http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
http://moonbase.rydia.net/mental/blog/programming/double-checked-locking-considered-broken

in order to do multi threaded communication reliably you really should
just use the tools the threading library provides for synchronization
and locking.  If you don't you are likely to be bitten by compiler
optimizations

If you follow the articles and look at what the compiler can optimize
away or rearrange it does not take too long to follow that in order to
write good multi-threaded synchronization code you have to use a
lock/mutex or other similar tool from a threading library, event the
sleep and volatile does not guarentee the behavior you are looking
for....

> > and even if the compiler does not, the CPU might cache the value.
> > Using a mutex enforces the necessary barriers to make it safe.
>
> Does this also apply to all the other memory that's written by one thread
> any read by another, such as the pixels? If so, does a single mutex
> synchronize all caches of all the cpus?
> I was under the impression that it's the cpu's job to keep the caches
> coherent and keep writes in order. It should never be the case that 2 cpus
> see different values for the same address, unless one just wrote to that
> address and hasn't had time to communicate to the others yet.

When you use the library functions it assures that they are coherent.
If you don't use a memory barrier of some form or another you might
get things executing out of order.

See Scott Meyers and Andrei Alexandrescu paper
"C++ and the Perils of Double-Checked Locking"
http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf


> >> 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?
>
> I take that back. My latest benchmark shows no measurable difference.
>
> --Loren Merritt
>