[fpc-devel] volatile variables

[Jonas Maebe]

On 28 Jun 2011, at 15:39, Andrew Brunner wrote:

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

That's why libpthread includes memory barriers.

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

No, that is impossible. That's the whole point of using libraries such  
as libpthread. They abstract such issues away. Using atomic operations  
inside mutex sections only slows down your program unnecessarily  
(unless you also access the target memory location from code not  
guarded by that mutex, and also use atomic operations in those  
alternate cases -- or if you are using a synchronization primitive  
from a library that does not observe the same semantics as libpthread,  
but that would be a really strange design decision).

If what you write above would be true, almost no program using  
libpthread for synchronization would consistently work on multi-core  
systems. How many programs do you know that exclusively use atomic  
operations to access shared memory locations inside code regions  
guarded by a pthread_mutex?


Jonas