[fpc-devel] volatile variables

[Andrew Brunner]

On Tue, Jun 28, 2011 at 8:28 AM, Jonas Maebe <jonas.maebe at elis.ugent.be> wrote:

>> 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"?

"on die" image was meant to take you to the code on the actual core
being executed.  That is to say the core itself is ignorant of what
just executed before and will just take the code and execute it.

>> 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).

Sort of right.  6 core system. Core 1 locks code block.  Code block
should still use interlocked statements to make memory assignments so
that when Core 1 releases lock - Core 2 can have a real-time image of
variable.  Otherwise Core 2 may see a stale copy of the variable.

> 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.

Don't bother looking that deep.  The topic the poster raised is about
variable volatility with respect to thread safe code.