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

[Jonas Maebe]

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