Can I atomically increment a 16 bit counter on x86/x86_64?

Question

I want to save memory by converting an existing 32 bit counter to a 16 bit counter. This counter is atomically incremented/decremented. If I do this:

1. What instructions do I use for atomic_inc(uint16_t x) on x86/x86_64?
2. Is this reliable in multi-processor x86/x86_64 machines?
3. Is there a performance penalty to pay on any of these architectures for doing this?
4. If yes for (3), what's the expected performance penalty?

Thanks for your comments!

Answer 1

Here's one that uses GCC assembly extensions, as an alternative to Steve's Delphi answer:

uint16_t atomic_inc(uint16_t volatile* ptr)
{
    uint16_t value(1);
    __asm__("lock xadd %w0, %w1" : "+r" (value) : "m" (*ptr));
    return ++value;
}

Change the 1 with -1, and the ++ with --, for decrement.

Answer 2

Here is a Delphi function that works:

function LockedInc( var Target :WORD ) :WORD;
asm
        mov     ecx, eax
        mov     ax, 1
   Lock xadd    [ecx], ax
        Inc     eax
end;

I guess you could convert it to whichever language you require.

Answer 3

The simplest way to perform an atomic increase is as follows (this is inline ASM):

asm
  lock inc dword ptr Counter;
end;

where J is an integer. This will directly increase Counter in its memory location.

I have tested this with brute force and it works 100%.

Answer 4

To answer the other three questions:

1. Didn't find a way to make a numbered list starting with 2
2. Yes, this is reliable in a multiprocessor environment
3. Yes, there is a performance penalty
4. The "lock" prefix locks down the busses, not only for the processor, but for any external hardware, which may want to access the bus via DMA (mass storage, graphics...). So it is slow, typically ~100 clock cycles, but it may be more costly. But if you have "megabytes" of counters, chances are, you will be facing a cache miss, and in this case you will have to wait about ~100 clocks anyway (the memory access time), in case of a page miss, several hundred, so the overhead from lock might not matter.