On 28 Jun 2011, at 15:20, Andrew Brunner wrote:
On Tue, Jun 28, 2011 at 8:11 AM, Jonas Maebe <jonas.ma...@elis.ugent.be
> wrote:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html
(point 4.11)
Nope. Nothing about order - just access - and that is entirely on the
application level - not system.
1.) Code execution on die is not controlled by pthreads implemention -
as it is unaware at that level.
I have no idea what you mean by this. What would "code execution off
die" be as opposed to "code execution on die"?
2.) Blocking access as described in 4.11 does not address execution
order.
It does guarantee that if T1 locks the mutex, changes the value,
unlocks the mutex and then T2 acquires the mutex (either on another
cpu or not is irrelevant), then T2 will observe strict memory ordering
with respect to T1 as far as this memory location is concerned (i.e.,
it will see any changes to that memory location performed by T1 that
were protected by the mutex).
If by "execution ordering" you mean that there is no guarantee
regarding which thread will acquire the mutex first, then that's true,
but synchonrization races are unrelated to memory ordering issues.
Jonas
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
