6

I am looking at http://msdn.microsoft.com/en-us/library/aa691278(VS.71).aspx, which said read and write of int is atomic, while read and write of long may not be. Is that really true for 64 bit platform? Isn't it IntPtr.Size == 64 bit or long? Am I missing something or the language specs are not full enough?

More thoughts here as well: http://philosopherdeveloper.wordpress.com/2011/02/08/beware-assignment-atomic-assignment/

Schultz9999
  • 8,717
  • 8
  • 48
  • 87
  • Check out this one - http://stackoverflow.com/questions/881820/interlockedexchange-and-memory-alignment - alignment is important. – Alexei Levenkov Sep 18 '12 at 23:43
  • 1
    Are you working with C# 1.0 and .NET 1.1? If not, then you should probably ignore ancient documents like that. The specification is at http://go.microsoft.com/fwlink/?LinkId=199552. – John Saunders Sep 19 '12 at 01:52
  • @JohnSaunders: I just googled it. Do you think C# language specification changes much from version to version of .NET? – Schultz9999 Sep 20 '12 at 21:53
  • The C# language specification changes between versions of C#. It has nothing to do with .NET versions. – John Saunders Sep 21 '12 at 00:49

2 Answers2

13

long is an atomic write on CPUs and platforms that have 64-bit words. e.g. if you run a 32-bit .NET application on a 64-bit computer, writes to long will not be atomic.

Mind you, atomicity is almost pointless if you can't make sure the compiler doesn't optimize access to that type of variable. e.g. you can't decorate a long field with volatile.

Operations on 64-bit fields are guaranteed to be atomic only in a 64-bit runtime environment

http://www.albahari.com/threading/part4.aspx

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

http://blogs.msdn.com/b/ericlippert/archive/2011/05/31/atomicity-volatility-and-immutability-are-different-part-two.aspx

Peter Ritchie
  • 35,463
  • 9
  • 80
  • 98
  • Ah! That's the catch. Thanks! What's the source of this info? – Schultz9999 Sep 18 '12 at 23:37
  • @Schultz9999 I've added some quotes and references detailing the same information. – Peter Ritchie Sep 19 '12 at 22:57
  • "long is an atomic write on CPUs and platforms that have 64-bit words" - that's not entirely true and there may be exceptions. 1. AFAIK there's no guarantee that the Complier would never split the 64-bit mov into two 32-bit ones. The C# spec does not mandate atomicity of 64-bit operations. 2. Even the CPU itself does not guarantee atomicity, for example if the two 32-bit parts are split across different cache lines. These are quite rare exceptions but they should be considered as well. – valiano Jul 08 '19 at 06:10
  • @valiano on a 32-bit processor or a 32-bit target that is true, but not on a 64-bit processor targeting a 64-bit processor – Peter Ritchie Jul 09 '19 at 03:38
  • 1
    Thanks @PeterRitchie - I was looking at the C# spec, but missed the fact that the CLI spec assures 64-bit accesses are atomic (where native int is 64-bit), as mentioned in the quoted blog post. Cheers – valiano Jul 09 '19 at 05:48
  • yeah @valiano, the whole story is across a few specs, unfortunately. – Peter Ritchie Jul 10 '19 at 15:43
1

That's the documentation for VS2003 which corresponds to .NET Framework 1.1, which was only available in a 32-bit flavour (ignoring the very niche IA-64 editions for now).

The .NET Framework 2.0 introduced the x64 edition, where (as long as you're running in 64-bit mode) then certain (but not all) Int64 operations will be atomic.

Of course, if you want to be certain, use the Interlocked class.

Dai
  • 141,631
  • 28
  • 261
  • 374