Question

This question has been asked before but i still don’t understand it fully so here it goes.

If i have a class with a property (a non-nullable double or int) – can i read and write the property with multiple threads?

I have read somewhere that since doubles are 64 bytes, it is possible to read a double property on one thread while it is being written on a different one. This will result in the reading thread returning a value that is neither the original value nor the new written value.

When could this happen? Is it possible with ints as well? Does it happen with both 64 and 32 bit applications?

I haven’t been able to replicate this situation in a console

Answer 1

If i have a class with a property (a non-nullable double or int) – can i read and write the property with multiple theads?

I assume you mean “without any synchronization”.

double and long are both 64 bits (8 bytes) in size, and are not guaranteed to be written atomically. So if you were moving from a value with byte pattern ABCD EFGH to a value with byte pattern MNOP QRST, you could potentially end up seeing (from a different thread) ABCD QRST or MNOP EFGH.

With properly aligned values of size 32 bits or lower, atomicity is guaranteed. (I don’t remember seeing any guarantees that values will be properly aligned, but I believe they are by default unless you force a particular layout via attributes.) The C# 4 spec doesn’t even mention alignment in section 5.5 which deals with atomicity:

Reads and writes of the following data types are 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 are also atomic. Reads and writes of other types, including long, ulong, double, and decimal, as well as user-defined types, are not guaranteed to 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.

Additionally, atomicity isn’t the same as volatility – so without any extra care being taken, a read from one thread may not “see” a write from a different thread.