"Martin v. Löwis" <[EMAIL PROTECTED]> writes: > > I think that has to be on a single processor, or at most a dual core > > processor with shared cache on die. With multiple cpu chips I don't > > think can get the signals around that fast. > > Can you explain what you mean? The lock# signal takes *immediate* > effect, within the CPU cycle in which it is asserted. There is no > delay whatsoever (except for speed-of-light issues, of course).
I dunno about x86 hardware signals but these instructions do read-modify-write operaitons. That means there has to be enough interlocking to prevent two cpu's from updating the same memory location simultaneously, which means the CPU's have to communicate. See <http://en.wikipedia.org/wiki/MESI_protocol> (I think this is how the current x86's do it): A cache that holds a line in the Modified state must snoop (intercept) all attempted reads (from all of the other CPUs in the system) of the corresponding main memory location and insert the data that it holds. This is typically done by forcing the read to back off (i.e. to abort the memory bus transaction), then writing the data to main memory and changing the cache line to the Shared state. A cache that holds a line in the Shared state must also snoop all invalidate broadcasts from other CPUs, and discard the line (by moving it into Invalid state) on a match. It is quite difficult to get signals off of a chip at GHz speeds, and so this signalling is much slower than the CPU cycle. -- http://mail.python.org/mailman/listinfo/python-list
