On 09-12-28 上午11:00, Samuel Thibault wrote: > 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. I don't understand. Do you mean processing cache line invalidation in local 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 :) Doesn't the intel processor maintain cache coherency by hardware? All instructions that modify memory should invalidate relevant cache lines in other processor. > >> 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 atomic_add_return can be used for implementing something like locks, so the clobber for the compiler cannot be dropped. >> 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? I'm confused by whether memory barrier instructions imply cache coherency. The memory model usually says all other cache lines can be updated *eventually*. It doesn't say that memory barrier instructions can update cache lines in other processors. So does the data dependency barrier invalidate all out-of-date cache lines in the local processor?
Zheng Da
