Hi, Samuel Thibault wrote: > (I've cleaned To: and subject a bit :) > > Da Zheng, le Wed 23 Dec 2009 21:23:23 +0800, a écrit : >> Samuel Thibault wrote: >>>> Is there anything else we should worry about? >>> Ordering. See /usr/src/linux/Documentation/memory-barriers.txt >> It's a long file. There are a lot to study:) > > Yes, it's very instructive. After I read this introduction, I checked some atomic operations implementation such as atomic_add_return in Linux for Aphla processors. Before and after these operations change the variable, they put memory barriers. So it's something like this: smp_mb(); operations; smp_mb();
But the problem is: on SMP, a variable's value can always been changed by another processor after the first memory barrier is called. Thus, the CPU does an operation on the stale value. There seems to be no way that we can guarantee that the variable has the latest value at the moment the CPU is doing the operation on it. >> Does it mean all machines have to provide at least one instruction >> that can modify variables in memory direct? so we can implement >> spin_lock or something similar. > > Yes. An architecture that wouldn't provide at least an atomic test and > set would be a nightmare to program (just memory barriers is theorically > enough, but it's a nightmare :) ) > So it's still doable. But I won't go deeper. Those algorithms can probably make my head explode:) Zheng Da