3

On 32-bit machines, reading and writing of 64-bit values in .net used to be non-atomic, i.e. when reading, I could read a value that had never been written to memory, consisting of one older 32-bit half, and one newer half.

  1. But are reads/writes atomic on 64-bit cpus?
  2. If so, does the (Windows) OS have to be 64-bit as well?
  3. And if so, would even the app have to be a 64-bit .net build?
Evgeniy Berezovsky
  • 18,571
  • 13
  • 82
  • 156
  • I have no idea about 1, but I can tell you that 2 and 3 are required. You need a 64-bit app in a 64-bit OS in a 64-bit CPU – Camilo Terevinto Oct 23 '18 at 23:44
  • .NET Apps/MSIL code is by default bitness agnostic. That means the same IL could eb executed as x32 or x64. And even x128 and x16 if we ever get runtiems for those. But you need a x64 OS (wich requires x64 hardware) to execute a x64 Programm. Usually windows supports "one step of binarity downward". Like the x32 Systems still supported x16 programms. And you can fix IL programms to only run at certain binarities in the project/solution build options. – Christopher Oct 23 '18 at 23:47
  • I only know Atomicity as a property of Database Systems. And in that context, nothing in computers is guaranteed to be save from Race Conditions unless you force it too. Or know exactly it is a single operation. Note for example that `i++` is just a shorthand for writing `i=i+1`. So it is still a read, then write operation, not a single readwrite operation. – Christopher Oct 23 '18 at 23:50
  • @JohnB please don't add useless tags – Camilo Terevinto Oct 23 '18 at 23:53
  • 1
    @CamiloTerevinto I readded the tag `32bit-64bit`, because I find it in fact pertinent to this question. – Evgeniy Berezovsky Oct 23 '18 at 23:55
  • 2
    define `useless` ... – jazb Oct 23 '18 at 23:56
  • What for, exactly? This is not about 32bit, but about 64bit. Even the tag reads "Issues related to the use of a 64bit vs a 32bit architecture", that's not at all this case. – Camilo Terevinto Oct 23 '18 at 23:59
  • 1
    @Christopher: The question is not about atomicity in the database sense but rather in the torn-reads sense. The point is that we do not need to consider complex operations like read-increment-write to get unexpected results. Even a read on one thread and a write on another can give unexpected results if the read and write are not atomic. – Eric Lippert Oct 24 '18 at 00:15
  • 2
    I am not sure why this question got a close-vote as off-topic. Its a good question and interesting performance question regarding threading (*UpVote*) also a continuation and relevant question asked from yesterday [Fastest way to safely read contents of long whose elements are changed concurrently](https://stackoverflow.com/questions/52939887/fastest-way-to-safely-read-contents-of-long-whose-elements-are-changed-concurr) – TheGeneral Oct 24 '18 at 01:29

1 Answers1

2

From this answer, if you're on a 64 bit system and using a 64-bit CLR, then they are atomic. The answer references this blog post from Eric Lippert: https://blogs.msdn.microsoft.com/ericlippert/2011/05/31/atomicity-volatility-and-immutability-are-different-part-two/

The CLI specification actually makes stronger guarantees. The CLI guarantees that reads and writes of variables of value types that are the size (or smaller) of the processor's natural pointer size are atomic; if you are running C# code on a 64 bit operating system in a 64 bit version of the CLR then reads and writes of 64 bit doubles and long integers are also guaranteed to be atomic. The C# language does not guarantee that, but the runtime spec does. (If you are running C# code in some environment that is not implemented by some implementation of the CLI then of course you cannot rely upon that guarantee; contact the vendor who sold you the runtime if you want to know what guarantees they provide.)

kristianp
  • 5,496
  • 37
  • 56
  • 1
    Note also that the reads and writes have to be aligned. A processor is allowed to tear reads if, say, you are dereferencing a pointer to a four-byte structure that has an odd-numbered address. – Eric Lippert Oct 24 '18 at 00:17
  • I guess `running C# code [..] in a 64 bit version of the CLR` would exclude 32-bit builds running inside a 64-bit CLR (via WOW64). – Evgeniy Berezovsky Oct 24 '18 at 00:39