On 28 Jun 2011, at 15:39, Andrew Brunner wrote:
On Tue, Jun 28, 2011 at 8:28 AM, Jonas Maebe <jonas.ma...@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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
