"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> Ah, but in the case where the lock# signal is used, it's known that
> the data is not in the cache of the CPU performing the lock operation;
> I believe it is also known that the data is not in the cache of any
> other CPU. So the CPU performing the LOCK INC sequence just has
> to perform two memory cycles. No cache coherency protocol runs
> in that case.
Paul Rubin wrote:
> How can any CPU know in advance that the data is not in the cache of
> some other CPU?
In the case where the LOCK# signal is asserted the area of memory
accessed is marked as being uncachable. In a SMP system all CPUs must
have the same mapping of cached and uncached memory or things like this
break. In the case where the LOCK# signal isn't used, the MESI
protocol informs the CPU of which of it's cache lines might also be in
the cache of another CPU.
> OK, this is logical, but it already implies a cache miss, which costs
> many dozen (100?) cycles. But this case may be uncommon, since one
> hops that cache misses are relatively rare.
The cost of the cache miss is the same whether the increment
instruction is locked or not.
Ross Ridge
--
http://mail.python.org/mailman/listinfo/python-list
