On Fri, 21 Jul 2000, Keith Owens wrote:
> On Thu, 20 Jul 2000 19:40:34 -0700,
> "Linda Walsh" <law@sgi.com> wrote:
> >But is it possible that I could change the value on 1 Processor and that
> >doesn't get invalidated in the caches of other Processors -- I think that should
> >work on the x86, but I completely don't know on other architectures.
>
> Linux SMP assumes cache coherent hardware. From a note by David Miller
> to l-k in 1996 and AFAIK never rescinded :-
>
> e) Currently, it is assumed that coherence in a
> multiprocessor environment is maintained by the
> cache/memory subsystem. That is to say, when
> one processor requests a datum on the memory bus
> and another processor has a more uptodate copy,
> by whatever means the requestor will get the
> uptodate copy owned by the other processor.
>
> (NOTE: SMP architectures without hardware cache coherence
> mechanisms are indeed possible, the current flush
> architecture does not handle this currently. If at
> at some point a Linux port to some system where this
> is an issue occurrs, I will add the necessary hooks.
> But it will not be pretty.)
I'm afraid this isn't the whole story, as there's still the matter of
speculative reads. That is, reads can be speculatively moved back in time
so that they occur before the write on the other processor.
The notion of concurrence is rather fuzzy here anyway - the communication
latency between processors means that each processor sees every other
processor as it was in the immediate past, but never the present.
To answer Linda's original question, whether it's necessary to use a lock
is very much dependent on the operation you're performing. It's safe to
assume there's an arbitrarily long delay before your write appears to
another processor, but we're also currently assuming that all writes show
up in the order they were performed.
-- "Love the dolphins," she advised him. "Write by W.A.S.T.E.."- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jul 23 2000 - 21:00:14 EST