What (if any) is the C# equivalent of the x86 asm xchg
instruction?
With that command, which imo is a genuine exchange (unlike Interlocked.Exchange
), I could simply atomically swap two ints, which is what I am really trying to do.
Update:
Sample code based upon my suggestion. Variable suffixed "_V" are decorated as volatile:
// PART 3 - process links
// prepare the new Producer
address.ProducerNew.WorkMask_V = 0;
// copy the current LinkMask
address.ProducerNew.LinkMask_V = address.Producer.LinkMask_V;
// has another (any) thread indicated it dropped its message link from this thread?
if (this.routerEmptyMask[address.ID] != 0)
{
// allow all other bits to remain on (i.e. turn off now defunct links)
address.ProducerNew.LinkMask_V &= ~this.routerEmptyMask[address.ID];
// reset
this.routerEmptyMask[address.ID] = 0;
}
// PART 4 - swap
address.ProducerNew = Interlocked.Exchange<IPC.Producer>(ref address.Producer, address.ProducerNew);
// PART 5 - lazily include the new links, make a working copy
workMask = address.Producer.LinkMask_V |= address.ProducerNew.WorkMask_V;
Note the lazy update.
This is the likely implementation for Interlocked.Exchange() in the CLR, copied from the SSCLI20 source:
Note that UP in the function name means UniProcessor. This is not atomic on SMP / multi-core systems. This implementation will only be used by CLR on single-core systems.
FASTCALL_FUNC ExchangeUP,8
_ASSERT_ALIGNED_4_X86 ecx
mov eax, [ecx] ; attempted comparand
retry:
cmpxchg [ecx], edx
jne retry1 ; predicted NOT taken
retn
retry1:
jmp retry
FASTCALL_ENDFUNC ExchangeUP
It is superior to using XCHG because this code works without taking a bus lock. xchg
has an implicit lock
prefix, so unlike xadd
or cmpxchg
it simply can't be omitted for single-core systems to still do the operation in one instruction to make it atomic with respect to interrupts (and thus other threads on uniprocessor).
The odd looking jumping code is an optimization in case branch prediction data is not available. Needless to say perhaps, trying to do a better job than what has been mulled over for many years by very good software engineers with generous helpings from the chip manufacturers is a tall task.