Re: SMP, barriers, etc.

[Samuel Thibault]

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