Re: How to do atomic read?

Exactly

the InterlockedExchange() implementation in the ntkrnlmp looks like

xchg edx, [ecx]
mov eax, edx
retn
..

"Anton Bassov" <AntonBassov@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:E43947F7-0A80-4461-8C18-E3D3C7486E0B@xxxxxxxxxxxxxxxx
rather than by InterlockedXXX functions. These functions use LOCK
prefix
that

not all of them

Actually, it looks like they all do (at least in the user mode under XP
SP2), although,
according to their names, not all of them have to - I fully agree with
you
here. For example, if InterlockedExchange() relied upon XCHG instruction,
as
it name suggests, it would not have to use LOCK prefix, because LOCK is
automatically assumed for XCHG instruction. However, for this or that
reason
it uses CMPXCHG exactly like InterlockedCompareExchange() does, so that it
needs LOCK prefix.

Anton Bassov

"Andrew Sha" wrote:

rather than by InterlockedXXX functions. These functions use LOCK
prefix
that

not all of them

"Anton Bassov" <AntonBassov@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:F4120CD8-0F84-48CC-8AE5-FCFD99D831B0@xxxxxxxxxxxxxxxx
But atomic reads are silly.

Actually, they are not, but in context of this discussion they are -
atomicity of reads and writes should be achieved by proper aligninment,
rather than by InterlockedXXX functions. These functions use LOCK
prefix
that
does not apply to MOV instruction, i.e. to reads and writes - if you
use
it
with MOV, CPU is going to raise an exception. Therefore, InterlockedXXX
functions should be used not for reads and writes but for increments,
decrements, exchanges and other operations
that can be used with LOCK prefix ( please consult Volume 2 of Intel
Developer's Manual for the list of instructions that can be used with
LOCK
prefix )


When it comes to atomicity of reads and writes, it should be achieved
simply
by proper aligninment. One-byte memory access with MOV instruction is
always
atomic, as well as as WORD and DWORD ones that are aligned on
respectively
WORD and DWORD boundary.

Anton Bassov


"Mark Roddy" wrote:

0dbell@xxxxxxxxx wrote:
On Jun 20, 9:11 am, "Alexander Grigoriev" <a...@xxxxxxxxxxxxx>
wrote:
<0db...@xxxxxxxxx> wrote in message

But, in case I am not seeing the obvious, what's wrong with:
LONG asignee = InterlockedExchange(&var, var);
First, it's NOT atomic. There is a window for change. This IS
atomic:

LONG asignee = InterlockedCompareExchange(&var, 0, 0);

Thanks for the correction. Can you explain why?

Yeah, I'd be fascinated by that explanation. But atomic reads are
silly.
What is the point?






.

Relevant Pages

  • Re: whats the use of "data16 nop" instruction generated by gas on x86 and x86_64
    ... The basic problem is that there aren't different instruction encodings for 16-bit and 32-bit operations; a code segment has a "default" operand size, and if you want the "other" size, you need the 66h prefix. ... For instance, in 16-bit mode a "MOV AX, BX" can be turned into "MOV EAX, EBX" by adding a 66h prefix. ... 90h is the opcode for XCHG AX,AX, so adding one or more 66h prefix bytes change the code from 16 to 32 bit or vice versa. ... BTW, MOVing any register to itself is a two-byte NO-OP, but unlike the 66h/90h combination it isn't specialcased by the decoder, so it does affect the reorder buffer register pressure. ...
    (comp.arch)
  • disassembler prefix-byte check -- wanting comments good and bad
    ... check the description down at the very bottom of the snippet if things get ... prefix bytes... ... mov cl,al ... jmp next_prefix ...
    (alt.lang.asm)
  • Re: mov seg, reg/mov reg, seg and size prefix
    ... size prefix byte, for 16-bit only instructions, is all over the map. ... mov ds, ax ... assembler that *was* doing it, at that time. ...
    (comp.lang.asm.x86)
  • disassembler prefix-byte check -- wanting comments good and bad
    ... check the description down at the very bottom of the snippet if things get ... prefix bytes... ... mov cl,al ... jmp next_prefix ...
    (comp.lang.asm.x86)
  • Re: mov seg, reg/mov reg, seg and size prefix
    ... size prefix byte, for 16-bit only instructions, is all over the map. ... mov ds, ax ... But it seems "wrong" to me for an assembler to emit *any* unneeded byte. ...
    (comp.lang.asm.x86)