[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SMP, barriers, etc.

From: Da Zheng
Subject: Re: SMP, barriers, etc.
Date: Mon, 28 Dec 2009 19:15:16 +0800
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: Gecko/20091204 Thunderbird/3.0

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 
>> 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
>> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]