[fpc-devel] volatile variables
jonas.maebe at elis.ugent.be
Tue Jun 28 15:50:09 CEST 2011
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
>> to that memory location performed by T1 that were protected by the
> 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?
More information about the fpc-devel