Brad Wilson <[EMAIL PROTECTED]> wrote: > Sure, I know what it means. I've been using them since around 1992. :) > > I don't think it's appropriate to call them "lock free", nor to say they > "won't block other threads". Neither statement is true.
I think you're being disingenuous. It won't block other threads, as threads are an OS concept, and "blocking a thread" is an statement at the OS level. A blocked thread is a thread that the OS won't schedule for execution until it's marked ready, by IO completion or releasing a lock, etc. > The LOCK modifier halts the other CPU(s) on multiprocessor boxes while the > instruction is executed. If that CPU is running another thread, then it's > blocked. That's not what the Intel docs say. Quote from Vol 2A of IA32 docs, on the LOCK-Assert prefix: "Causes the processor’s LOCK# signal to be asserted during execution of the accompanying instruction (turns the instruction into an atomic instruction). In a multiprocessor environment, the LOCK# signal insures that the processor has exclusive use of any shared memory while the signal is asserted. Note that, in later Intel 64 and IA-32 processors (including the Pentium 4, Intel Xeon, and P6 family processors), locking may occur without the LOCK# signal being asserted. See the “IA-32 Architecture Compatibility” section below." "Beginning with the P6 family processors, when the LOCK prefix is prefixed to an instruction and the memory area being accessed is cached internally in the processor, the LOCK# signal is generally not asserted. Instead, only the processor’s cache is locked. Here, the processor’s cache coherency mechanism insures that the operation is carried out atomically with regards to memory. See “Effects of a Locked Operation on Internal Processor Caches” in Chapter 7 of Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A, the for more information on locking of caches." Quote from Vol 3A, section 7.1.2.2: "A locked instruction is guaranteed to lock only the area of memory defined by the destination operand, but may be interpreted by the system as a lock for a larger memory area." I would guess this behaviour is caused by cache coherency logic being used to implement LOCK, going by what the previous quote says. I would interpret this as meaning that other multiprocessors are only stalled on memory access if they are contending for the same section of memory, or coincidentally as and when the cache coherency logic decides. > Now, the amount of time that it's blocked is very small (the space of a > single instruction). Calling it a "lightweight lock" is appropriate. Calling > it "lock free" is not. I think you've redefined "lock". If words mean what you want them to mean, all arguments are winnable :) -- Barry -- http://barrkel.blogspot.com/ =================================== This list is hosted by DevelopMentor� http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
