Are MSIL atomic?

Question

I played a little with the MSIL decompiler - ILDASM, and I tried to decompile a simple .NET method.

The operation codes looked something like this:

.method private hidebysig static int32 Add(int32 a, int32 b) cil managed { // Code size 18 (0x12) .maxstack 2 .locals init ([0] int32 c, [1] int32 d, [2] int32 CS$1$0000) IL_0000: nop IL_0001: ldarg.0 IL_0002: ldc.i4.5 IL_0003: add IL_0004: stloc.0 IL_0005: ldarg.1 IL_0006: ldc.i4.s 10 IL_0008: add IL_0009: stloc.1 IL_000a: ldloc.0 IL_000b: ldloc.1 IL_000c: add IL_000d: stloc.2 IL_000e: br.s IL_0010 IL_0010: ldloc.2 IL_0011: ret } 

I wonder are these atoms an atom? ie In the case of a proactive scheduling kernel, is it possible for one opcode to be unloaded before completion? The operation code here can easily be compared with asm instructions to a large extent 1: 1, as they have separate operation codes for loading, storing, adding, etc.

But what about more complex opcodes? like a “call” when the operand is the token of the reference method, which must first follow in order to resolve the method and then called? is it also an atom?

Answer 1

No, not all opcodes are atomic. For example, if you use stloc or ldloc for value types that are larger than the native size of a pointer that is not guaranteed to be atomic.

Section 12.6.6 of ECMA 335 guarantees this:

The corresponding CLI must ensure that read and write access to correctly aligned memory cells does not exceed the size of the native word (size of type native int) is atomic (see 12.6.2) when all write accesses to the location are the same size. Atomic records should not change any bits other than those written.

... but then there is a note:

[Note. Guaranteed atomic access to 8-byte data is not possible if the size of the int int is 32 bits, although some implementations can perform atomic operations when the data is aligned on an 8-byte boundary. end note]

So this means that any op code that stores or reads Int64 is not guaranteed to be atomic on x86, for example ...

Answer 2

I do not think atomicity is defined in IL instructions. It is defined in terms of loads and stored from / to memory.

And the atomicity rules for cargo and stores are complex. They are related to the alignment and size of the stored value.

Your “call” example does not make sense: it does not access memory. The concept of atomicity is not related to a call statement.