Is lock xchg/cmpxchg memory address safe on SMP?
jhutc...@gmail.com
lock the bus on SMP and is thus a safe test and set to gain a lock in
SMP. But I have also read that it only locks the processor cache. Is
there any scenario where XCHG on memory is not SMP safe?
Rod Pemberton
<jhutc...@gmail.com> wrote in message
news:8e83a890-3227-40a5...@e6g2000prf.googlegroups.com...
LOCK isn't needed with XCHG. Why would you want to use them together?
XCHG says:
"If a memory operand is referenced, the processor's locking protocol is
automatically implemented for the duration of the exchange operation,
regardless of the presence or absence of the LOCK prefix or of the value of
the IOPL."
XCHG also says:
"This instruction is useful for implementing semaphores or similar data
structures for process synchronization."
LOCK says:
"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."
LOCK also says:
"The XCHG instruction always asserts the LOCK# signal regardless of the
presence or absence of the LOCK prefix."
> But I have also read that it only locks the processor cache.
As I understand it, that's not quite the same as what it says:
"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 IA-32 Intel® Architecture Software Developer's Manual, Volume 3A, the
for more information on locking of caches."
To me, the manual says for instructions on a P6 or later with the LOCK
prefix the cpu won't apply the LOCK# signal if the memory is in the
processor cache. But, the processor will lock the cache for these
instructions and guarantee that the operation is atomic. However, the
manual also says XCHG always ignores the LOCK prefix (quote above) and
always applies the LOCK# signal. Since it applies the LOCK# signal always,
the caching issue should be irrelevant for XCHG instruction.
> Is there any scenario where XCHG on memory is not SMP safe?
Not sure... But, I'd say: "No." since XCHG always applies the LOCK#
signal. To me, it also says other instructions useable with the LOCK prefix
are SMP safe too.
LOCK also says there is a chapter in the manual on it. Perhaps, it covers
exceptions to "SMP safe" usage:
"See 'Effects of a Locked Operation on Internal Processor Caches' in Chapter
7 of IA-32 Intel® Architecture Software Developer's Manual, Volume 3A, the
for more information on locking of caches."
Rod Pemberton
Wolfgang Kern
jhutchence asked:
I have two variants in my book:
___________ KESYS MP solutions x86
CHECK_GRANT_HLL:
mov ecx,false ;assuming true means 'free' yet.
mov eax,true
lock cmpxchg,dw global_grant_if_free, ecx
;eax true means granted and modified to false
;eax false means occupied
ret ; also possible: jz granted...
___________ KESYS MP solutions x86
CHECK_GRANT_ASM:
mov eax,grant_if_free_bitnr ;can span a range +/-256MByte
lock bts dw global_flags,eax
;a set CY means the flag was SET and remains SET(occupied)
;NC means granted and SET now
jnc granted
...
___________
XCHG got an implied LOCK, but is not a good solution for
a save atomic spin lock, LOCK CMPXCHG is designed for it
and BTS works as well even not too HLL friendly.
__
wolfgang
maz...@centrum.cz
In your book? Can you be more specific?
Wolfgang Kern
mazegen asked:
>> I have two variants in my book:
> In your book? Can you be more specific?
My personal notes (most still handwritten on paper) span several
'books' already, but I never published the 'Holy book of KESYS' :)
__
wolfgang
maz...@centrum.cz
What does KESYS mean? :)
Wolfgang Kern
mazegen asked:
>>> In your book? Can you be more specific?
>> My personal notes (most still handwritten on paper) span several
>> 'books' already, but I never published the 'Holy book of KESYS' :)
> What does KESYS mean? :)
That is the name of my OS since 1990, predated versions were called
HEX_WORK85, KEMM, LEOC, but this oldies weren't standalone systems
and worked as DOS-override/extenders.
Because of my logo I spell it K-E-sys. Google may show you more
info about it, even I haven't updated it for some years ...
__
wolfgang
Wolfgang Kern
I wrote:
> mazegen asked:
How impolite am I today ? here's the link: