You are right. You will see the assignment or you won't see it. Assignments (and reads) of references are always "atomic" (in the end it's because on 32 bits machines references are 32 bits, so can be done atomically, and on 64 bits machines (running a 64 bits app) references are 64 bits, so can be done atomically. The only exception is trying to write/read a long (64 bits) on a 32 bits machine. There you would have to use Interlocked.Read / Interlocked.Exchange)
Normally should declare status as
volatile, so that each thread sees only the latest version. You should read this: http://www.albahari.com/threading/ it's very very good!
If you don't trust me, read the section
Do We Really Need Locks and Barriers? here http://www.albahari.com/threading/part4.aspx
Ah... I was forgetting... The world HATES you, so there is a little thing to know of volatile: sometimes it doesn't work :-) :-) Read, in the same page of the other example, the section
The volatile keyword, the part UNDER the red box.
Notice that applying volatile doesn’t prevent a write followed by a read from being swapped, and this can create brainteasers. In the end, the only way to be sure is to use
Interlocked.Exchange to write and
Interlocked.CompareExchange to read something OR protect the read and the write sections with synchronization (like
lock) OR fill your program with Thread.MemoryBarrier (but don't try it, you'll fail, and you won't even know why). You are guaranteed that all the reads and the writes done in the lock will be done IN the lock, not before or after.