[fpc-devel] volatile variables
jonas.maebe at elis.ugent.be
Tue Jun 28 15:28:33 CEST 2011
On 28 Jun 2011, at 15:20, Andrew Brunner wrote:
> On Tue, Jun 28, 2011 at 8:11 AM, Jonas Maebe <jonas.maebe at elis.ugent.be
> > wrote:
>> (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
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.
More information about the fpc-devel