Is Updating Double Operation Atomic

Is Updating double operation atomic

This is hardware specific and depends an the architecture. For x86 and x86_64 8 byte writes or reads are guaranteed to be atomic, if they are aligned. Quoting from the Intel Architecture Memory Ordering White Paper:

Intel 64 memory ordering guarantees
that for each of the following
memory-access instructions, the
constituent memory operation appears
to execute as a single memory access
regardless of memory type:

1. Instructions that read or write a single byte.

2. Instructions that read or write a word (2 bytes) whose address is
   aligned on a 2 byte boundary.

3. Instructions that read or write a doubleword (4 bytes) whose address is
   aligned on a 4 byte boundary.

4. Instructions that read or write a quadword (8 bytes) whose address is
   aligned on an 8 byte boundary.

All locked instructions (the implicitly
locked xchg instruction and other
read-modify-write instructions with a
lock prefix) are an indivisible and
uninterruptible sequence of load(s)
followed by store(s) regardless of
memory type and alignment.

Is nullable double and decimal update atomic on x64 system?

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.

Is double read atomic on an Intel architecture?

Yes and no. On 32-bit processors, it is not guaranteed atomic, because double is larger than the native wordsize. On a 64-bit processor properly aligned access is atomic. The 64-bit CLI guarantees everything up to a 64-bit read as atomic. So you'd need to build your assembly for x64 (not Any CPU). Otherwise if your assembly may be run on 32-bit, you better use Interlocked, see Atomicity, volatility and immutability are different, part two by Eric Lippert. I think you can rely on Eric Lippert's knowledge of the Microsoft CLR.

The ECMA CLI standard also supports this, even though C# itself does not guarantee it:

A conforming CLI shall guarantee that read and write access 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)

It also says that on processors where operations are atomic, Interlocked methods are often compiled to a single instruction, so in my book there is no performance penalty in using it. On the other hand, there may be a worse penalty to not using it when you should.

Another related Stack Overflow question is What operations are atomic in C#?.

When updating two columns of one record, is such change is atomic?

In theory ALL transactions are atomic -- can't guarantee no possible bug in sql server could break this.

If you don't speficy an explicit transaction, each statement is its own transaction.

Power failures, etc. don't cause a problem because the transaction log is applied on restart.

ADDED

Re: comment about prior question 21468742

Sorry, I don't think so -- a lot to read there, but I saw nothing violating atomicity there, it appeared to be a confusion of atomicity and isolation. And I see that Martin Smith came to the same conclusion. Think of it this way, when you update stuff like this you are updating a disk block by rewriting the whole block (or database base page). With a log and commit architecture the whole block is written and committed, or none of it is. In case of P/F the last good write is known, and if a failed write happens and it not marked complete it is not applied to the database from the tranlog on restart.

---

Related Topics