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?
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) > Furthermore, FPC supports many more architectures than just x86, and > on (virtually?) all other platforms the instructions for atomic > accesses do not automatically imply any kind of memory barrier. Of course, I only used this piece of pseudo-assembly since it conveys the message enough to understand each other. -- Ewald
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
