[x264-devel] Re: bug in commit 607

[TK]

Loren Merritt <lorenm at u.washington.edu> writes:
>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,

(PMFJI)
It is almost true with all IA32, but not with Itanium.

On Itanium smp system, one thread can runs forever reading zero from a 
memory
address while other thread(s) writing one to same memory address, unless 
executing
valid memory barrier operations. Even the order of cache flushing are not 
same as
the order of program code.

That is, these code bellow could causes exception in Itanium

Thread#1
 a_pointer = some_valid_addr;
 a_available = true;

Thread#2
 if (a_available) v = *a_pointer;

because one Itanium may flush the value of a_available BEFORE that of 
a_pointer,
to shared memory. I don't know usleep() causes memory barrier operation or 
not,
but I think it doesn't. Process switching would causes memory barrier, so 
these
kind of code may work and resulting ,hard to find, race condition.

Itanium's memory model may looks silly, but Itanium is designed for server 
system
and to keeping coherency between many in-depend server process is too 
expensive job.

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