Da Zheng, le Mon 28 Dec 2009 10:31:26 +0800, a écrit : > On 09-12-27 下午6:38, Samuel Thibault wrote: > > Da Zheng, le Sun 27 Dec 2009 16:39:04 +0800, a écrit : > >> Is the process above correct? > > > > I have never actually programmed the architectures where things work > > like this (powerpc & such), but that's what I have understood from the > > code and explanations here and there, yes. It's a sort of transactional > > memory actually. > I just think if it's a bit too expensive that a processor has to monitor other > processors' cache even though it's only one address.
It's not more expensive than usual operations: it already has to do it to process cache line invalidations for everything that is in the cache. > That conditional store instruction needs to do more if it succeeds. It has to > invalidate cache lines specified by the monitored address in other processors. Locked operations on Intel have to do the same :) > Now it seems to me that the memory barrier is only to ensure that the > processor > executes instructions in the order we want. Not only that, but also as a clobber for the compiler. Note however that atomic_add doesn't have it, and I believe it could be dropped for add_return too. In Linux, atomic.h operations do _not_ necessarily provide "lock/release" semantic: out of order stores can happen for variables other than the atomic counter. I.e. one can't use an atomic_t as a spinlock, it's just meant to be an atomic counter and not protect something else. > But the data dependency barrier > seems to imply cache coherency according to > linux/Documentation/memory-barriers.txt. Err, there is _some_ cache coherency introduced by dependency barriers, yes. > A bit confused:-( By what? Samuel
