Menu
Update: I just stumbled upon this in Eric Lippert's answer to another question (he is quoting the 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.
OK, so reading a double is not atomic. This means the value could get modified mid-read, right? So how does one read a double value atomically?
I notice there's an Interlocked.Read method for long values. This makes sense to me, as reading a 64-bit value must require two steps and therefore be subject to race conditions just like every other non-atomic action.
But there's no Interlocked.Read for double values, even though System.Double is a 64-bit value.
I am seeing some strange behavior in my program where my GUI, which displays a double in a text box while that double is also being frequently updated by other threads, is showing the correct value (in the vicinity of 200.0) most of the time, and then randomly showing an erroneous value (like -0.08) occasionally.
Maybe this is a threading issue, or maybe it's something else. But first off I wanted to narrow down the possiblities. So: is reading a double thread-safe?
868
So point is, in Java, long and double aren't thread safe. When multiple threads are going to access a long or a double value without synchronization, it can cause problems. To ensure atomic/thread safety, it is essential to use volatile to ensure changes made by one thread are visible to other threads.
It is thread safe if many threads are reading the same location, until no one attempts to write there. Save this answer. Show activity on this post. Reading from memory is thread-safe, reading from memory that can be written to at the same time isn't safe though.
Thread safety becomes a concern if there is at least a single entry point which can be accessed by multiple threads. If a piece of code is accessed by multiple threads and is calling other method/class/etc., then all this code tree becomes vulnerable.
So atomic operations on primitive data types are a tool to achive thread safety but do not ensure thread safety automatically because you normally have multiple operations that rely on each other. You have to ensure that these operations are done without interruption eg using Mutexes.
is reading a double thread-safe?
No. As the spec says
Reads and writes of other types, including long, ulong, double, and decimal, as well as user-defined types, are not guaranteed to be atomic.
Moving on.
This means the value could get modified mid-read, right?
Yes.
So how does one read a double value atomically?
You take a lock out around every access to the mutable variable.
And a question you didn't ask, but often gets asked as a follow-up to your questions:
Does making a field "volatile" make reads/writes of it atomic?
No. It is not legal to make a volatile field of type double.
141
The usual way: control access with a lock.
37
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
