25

I know that in .Net all 32-bit types (e.g, int, bool, etc) are thread safe. That is, there won't be a partial write (according to the specifications).

But, does the same apply for int? (nullable int)?

Sam
  • 7,252
  • 16
  • 46
  • 65
Jeremy
  • 44,950
  • 68
  • 206
  • 332

3 Answers3

44

The question is poorly worded, and hence the confusion in the answers so far. The question should be "are reads and writes to a variable of type int? guaranteed to be atomic?"

No, absolutely not. The spec is extremely clear on this point:

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.

It is entirely possible for a thread to read a partially written value from a shared-memory variable of nullable type.

For example, suppose you have an int? variable x which at present has the value null. It therefore contains an int, set to zero, and a bool, set to false. Now on another thread you write the nullable int "5" to x. It is perfectly legal for another thread to read the non-nullable int zero from x, because the "true" in the bool could be set before the 5 is set to the int.

Eric Lippert
  • 647,829
  • 179
  • 1,238
  • 2,067
  • I understand your example for int? .. but why are reads/writes to long, double and decimal not atomic? – MalcomTucker Jun 16 '10 at 07:59
  • @MalcomTucker: The 32 bit processor only guarantees that operations on variables are atomic if they are 32 bits. Long, double and decimal can require more than one operation to write or read the whole value because they are larger than 32 bits. – Eric Lippert Jun 16 '10 at 13:31
  • @MalcolmTucker: http://msdn.microsoft.com/en-us/library/system.threading.interlocked_members.aspx offers functionality to provide the ability to perform atomic operations on doubles and other types. – Brian Jun 16 '10 at 13:53
  • 7
    So then if you have a 64 bit application are reads and writes atomic for doubles? – William Jun 20 '12 at 14:18
  • 2
    @William - On Windows, 64 bit read/writes are atomic on a 64 bit processor if and only if you are creating a 64 bit app. If you are still writing a 32 bit app (very likely), you do not have 64 bit atomicity even on a 64 bit processor. I asked a question about this a while ago: http://stackoverflow.com/questions/27533611/are-64-bit-operations-atomic-for-a-32-bit-app-on-64-bit-windows. – Ian Nov 17 '15 at 17:33
  • 4
    @EricLipper's Answer - For folks who are newer to thread-safety considerations it would be helpful to note in the answer that whilst reads and writes to an integer are atomic, incrementing an atomic integer is NOT atomic as it includes a read and write. Got confused by this myself and was about to ask a new question titled "Whats the Use of Interlocked.Increment if Int is Atomic?". – Ian Nov 17 '15 at 17:36
13

No, since an int? is actually a struct (Nullable<int>) composed of an int and a bool.

Anton Tykhyy
  • 19,370
  • 5
  • 54
  • 56
  • 2
    @Eric: But, excepting conversion operators, there are no public static members on `Nullable`. – LukeH Jun 15 '10 at 17:06
  • @LukeH: what does that have to do with the question? – Eric Lippert Jun 15 '10 at 22:47
  • 1
    @Eric: My comment was in response to an earlier comment (since deleted) made by another Eric, claiming that some members of the `int?` type -- the public static members -- were thread-safe. – LukeH Jun 15 '10 at 23:23
3

From http://msdn.microsoft.com/en-us/library/b3h38hb0.aspx:

Any public static (Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe.

Samantha Branham
  • 7,350
  • 2
  • 32
  • 44
  • 5
    The problem is that `Nullable` has no public static members (unless you count the conversion operators to/from `T` itself). This is just boilerplate text which you'll find in the documentation for most objects on MSDN. – LukeH Jun 15 '10 at 17:04
  • 3
    Does the fact that it is common documentation copy make it less accurate? – Samantha Branham Jun 15 '10 at 17:50