Re: SMP, barriers, etc.

[Da Zheng]

Hi,

On 09-12-28 下午7:28, Samuel Thibault wrote:
>>> 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?
> 
> Yes: a processor already has to listen to what other processors want to
> do with data that it has in its cache.
Really? Is it scalable? Didn't you say cache coherency in most architecture is
done by software?
> 
>>>> 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?
> 
> Err, yes. But I guess that's also the case with the Alpha, no?
No, I don't think so. I believe Alpha has more relaxed model. I just read some
document about Alpha a few days when I discuss with you about SMP, so I'm not
100% sure.
>> 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?
> 
> Ah, no, it's just a barrier: it doesn't asserts that everything that
> happened in the machine is visible to the processor, that would be way
> too expensive. What it asserts is just the _ordering_ of visibility of
> the changes.  That's why in general a memory barrier is needed both at
> the read and the write side, so that both the writing processor and the
> reading processor cooperate on the ordering of the visibility of the
> changes.  That's much more lightweight for the hardware cache coherency
> protocol and still enough to implement locks, RCU lists etc.
OK. Combined with what you said above, when a processor writes new values to the
memory, hardware invalidates all cache lines that contains these variables
*immediately*. When another processor tries to access these variables, it can
have the problem of the ordering of visibility. That's where memory barrier
comes into play and one of its role is to assert the right order of visibility.
It makes sense. I complete misunderstood how cache coherency is implemented with
software. I sort of understand how memory coherency works now.

So when a write memory barrier instruction is executed, the processor has to
remember the order of writes, so the read memory barrier instruction executed on
another processor can somehow get the information?

Zheng Da