On 07 Feb 2013, at 14:29, Ewald wrote:
Once upon a time, on 02/07/2013 01:46 PM to be precise, Jonas Maebe
said:
On 07 Feb 2013, at 13:39, Ewald wrote:
Well, I always thought that the InterLoackedCompareExchange boiles
down
to [**]
.Lock CMPXCHG
Or something quite like that. The `.Lock` there is the important
part
since this does insure a memory barier.
It's only a memory barrier if you don't use SSE (or write-combined
memory, but that's generally only the case for memory mapped video
memory or so, and more of an issue for kernel mode code than for user
space).
Alright, this is getting interesting ;-) Yet I wonder:
InterlockedCompareExchange is atomic, then you need to find a way to
make sure that only one processor core (one thread in general) is
accessing the memory that contains the integer/pointer. So, since
InterlockedCompareExchange does not necessarily makes use of a memory
barrier, how could it be done?
The interlocked* routines only guarantee that that particular value is
updated in atomic way across multiple cores. It does not guarantee
anything about memory access performed before or after that
interlocked* call. The memory barriers are to ensure that all memory
accesses before the lock-primitive (such as Enter/
LeaveCriticalSection) are also synchronized across all cores.
Also, in case I misunderstood you and you are trying to say that if I
write using some instruction to a part of memory that contains or is
contained the integer/pointer (so there is some memory overlap) then
yes, I agree and it isn't a memory barrier anymore. But then again,
who
writes data to a locking variable other then the code that does the
locking? (same goes for a simple `lock:= 5;` for example)
Please read the documents linked in one of my previous mails, they
explain it in extensive detail.
Jonas
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
