internal class Employee
 {
     internal int concurrentState; 

     internal void SetConcurrentState(int concurrentStatus) 
     { 
         Interlocked.Exchange(ref this.concurrentState, concurrentStatus);
     }
     internal int GetConcurrentState() 
     { 
         return Interlocked.CompareExchange(ref this.concurrentState, 
                                            0, 
                                            -this.concurrentState); 
     }
}

Like the title says, is this the best way to implement a concurrent (atomic) integer in C#? I only need to get a value so the convoluted get method defeats the comparison operation. It seems that Microsoft would have provided a better way.

Addendum: @mjwills posted a link to the C Sharp spec and from it is this…

9.6 Atomicity of variable references Reads and writes of the following data types shall be atomic: bool, char, byte, sbyte, short, ushort,
uint, int, float, and reference types. In addition, reads and writes
of enum types with an underlying type in the previous list shall also
be atomic. Reads and writes of other types, including long, ulong,
double, and decimal, as well as user-defined types, need not be
atomic. Aside from the library functions designed for that purpose,
there is no guarantee of atomic read-modify-write, such as in the case
of increment or decrement.

However a CLI document says atomic ops are are garanteed only on the condition of proper word boundary alignment in linked this text…

A conforming CLI shall guarantee that read and write access of
built-in primitive value types and pointers to properly aligned memory
locations no larger than the native word size (the size of type native
int) is atomic (see §I.12.6.2) when all the write accesses to a
location are the same size.

Second Addendum: This answer to a similar question points out that later changing an int to a long might break atomicity of a read. So a good reason to use Interlocked.CompareExchange is to avoid relying on the inherent atomicity of a reaon on an int that might get revised to a long. This is now a closed question but if I were to answer it, I would answer that this is a good method and the risk of breakage was probably what I was thinking about when I wrote it (way back when). I would clean it up by using the equivalent Interlocked.CompareExchange(ref v, 0, 0).