Question

In most cases double and decimal type update on 64 bit system is an atomic operation cause these types are 64 bit. (decimal is 128bit so this is wrong, thanks for comments)

But when I update double? and decimal? type on 64 bit system will it be atomic? What is the size of double? and decimal?

I understand that atomicity is not guaranteed though I still interested if such update will be atomic in general scenario.

Answer 1

In most cases double and decimal type update on 64 bit system is atomic operation cause these types are 64 bit.

No, decimal is 128 bit to start with. Also note that running on a 64-bit computer doesn’t necessarily mean you’re running the 64-bit CLR. It’s not clear what you mean by “system” here.

So you shouldn’t even assume atomicity for decimal. Even on a 64-bit CLR, I wouldn’t want to rely on the atomicity of double, partly as it will depend on alignment. The C# specification explicitly states (section 5.5 of the C# 4 spec):

Reads and writes of other types, including long, ulong, double, and decimal, as well as user-defined types, are not guaranteed to be atomic.

So that makes the nullable side kinda pointless, but…

But when I update double? and decimal? type on 64 bit system will it be atomic? what is the size of double? and decimal?

Nullable<T> is basically a T field and a bool field. So the storage will be more than 64 bits for double, and more than 128 bits for decimal. The exact storage will quite possibly depend on the context, but basically I wouldn’t expect atomicity for operations with these types.

As others have said, you almost certainly don’t want to rely on anything that’s not guaranteed. Personally I’d almost always try to avoid lock-free coding in general. Try to use higher-level abstractions that are provided by the CLR/BCL teams and proven to be safe.