Once upon a time, on 02/08/2013 04:02 PM to be precise, Jonas Maebe said: > > 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. > > 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. Now I see, thanks for the explanation!
-- Ewald
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel