Re: xchg & lock question

"robertwessel2@xxxxxxxxx" <spamtrap@xxxxxxxxxx> wrote in message
news:1143497060.404031.267010@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Eman wrote:
For those, who may also being interesting in this topic,
the answer is as follows.

These are e.g. Pentium 4, Intel Xeon, and P6 family processors.
For them, if the memory area being accessed is cached internally
in the processor, the LOCK# signal is generally not asserted;
instead, locking is only applied to the processor's caches.
("IA-32 IntelR Architecture Software Developer's Manual,
Volume 3: System Programming Guide").

--

"Eman" <spamtrap@xxxxxxxxxx> wrote in message
news:e06vfn$2dlm$2@xxxxxxxxxxxxxxxxx
> According to Intel' manual "when a memory operand is used with the XCHG
> instruction, the processor's LOCK signal is automatically
> asserted". AMD documentation also states that.
>
> Can someone tell me, which of IA32 compatible processors do not
> assert LOCK automatically in the case of XCHG reg,[mem] ?


All IA32 processors automatically lock memory referencing XCHG
instructions, as do 286s. 8086/8 and 8018Xs did not.

You comment about the lock signal not being asserted outside of a
particular CPU when that CPU has the data item cached (specifically if
the processor has the cache line cached in an *exclusive* state), is
correct, but somewhat irrelevant. From a software perspective the
locked region does not have to exceed the actual memory operand
(although it often does), so "locked" access to an exclusive cache line
without asserting the actual inter-processor lock signal does not cause
a software visible change, except for being much, much, faster.

Thanks for feedback, Robert. As i understand, not only CPU
but some other hardware may be in game with the bus. Does it matter?

Actually i'm not asm/hardware geek, but sometimes i'm using
asm in multithreading code and must be sure of my locks in a
multiprocessor case. So i need clear reason and idea why
Microsoft prefers using explicit LOCK in InterlockedExchange API
rather than XCHG. Some other people also "wondered that" (example:
http://coding.derkeiler.com/Archive/Delphi/borland.public.delphi.language.basm/2003-10/0359.html)
The questions arise from this point. Windows DDK guru told me
that "XCHG does not have an implicit lock", i'm not inclined
to distrust, so how should i interpret that in conformity with
CPU / hardware terms?

.

Relevant Pages

  • Re: xchg & lock question
    ... the processor's LOCK signal is automatically ... All IA32 processors automatically lock memory referencing XCHG ... particular CPU when that CPU has the data item cached (specifically if ...
    (comp.lang.asm.x86)
  • Re: xchg & lock question
    ... AMD documentation also states that. ... assert LOCK automatically in the case of XCHG reg,? ...
    (comp.lang.asm.x86)
  • Re: lock# and Bus Locking
    ... > Section 7.1.2 ("Bus Locking") of the Intel System Programming Guide ... > during certain critical memory operations to lock the system bus. ... On a modern CPUs it is unlikely a lock against cacheable memory will assert ...
    (microsoft.public.win32.programmer.kernel)
  • Re: xchg & lock question
    ... assert LOCK automatically in the case of XCHG reg,? ... think *all* IA32 processors employ locking for this instruction. ...
    (alt.lang.asm)
  • Re: [ltt-dev] [RFC git tree] Userspace RCU (urcu) for Linux (repost)
    ... My confusion -- I was testing my old approach where the memory barriers ... I tried removing the second parity switch from the writer. ... LOCK operations. ...
    (Linux-Kernel)