[fpc-devel] Why FreeBSD sem_init() works different to Linux?
Florian Klämpfl
florian at freepascal.org
Fri Feb 8 19:06:27 CET 2013
Am 08.02.2013 16:02, schrieb Jonas Maebe:
>
> On 07 Feb 2013, at 16:52, Ewald wrote:
>
>> Altough I still
>> don't see how you can make these calls atomic then (without the
>> barrier)?
>
> On x86, it is impossible to perform an atomic access without a (partial)
> memory barrier that affects all memory (due to the behaviour of the
> "lock" prefix). On other architectures, the instructions for atomic
> accesses may only lock the cacheline or memory page containing the value
> to be atomically modified. I.e., they are only a barrier for that
> cacheline/page, not for the entire memory.
This might change with Haswell though (when the new instructions are used).
>
> Or not even that: older SPARC architectures only had a test-and-set
> instruction, which only supported switching between 0 and 1. So
> basically you had to use a single global lock variable, which you locked
> using this instruction, then you modified the "atomic value" using
> regular instructions, and then unlocked the global lock again. So any
> atomic update conflicted with any other atomic update, regardless of
> where the values were located, and there was no memory barrier
> whatsoever (except for this one lock variable). And it only worked if
> all code in the entire program made use of the same global lock
> variable. It's similar for older ARM CPUs.
More information about the fpc-devel
mailing list