[fpc-devel] Why FreeBSD sem_init() works different to Linux?

[Ewald]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20130207/3b9c7bc8/attachment.html>