C# volatile double

Question

As only reference types and a few primitives (including float, but not double, I'm not sure the reason why, I'm happy to hear why) can be declared as volatile, if I wrap a double in a class then declare it as volatile (as below), will the double property be 'read write' thread safe as any other volatile, or should I still be looking at locking?

public class MyThreadedClass
{
    volatile VolatileDouble voldub;
}

public class VolatileDouble
{
    public double Double { get; set; }
}

Answer 1

Reason why double can't be declared volatile: it's 64 bits, which makes it more than the word size on x86, which prevents it from being declared volatile in the CLI if I remember correctly.

With your current answer, only the reference is treated as being volatile. That means the memory model will make sure it always uses the most recent reference, but it could still use a stale value.

I'd go with locking if I were you, but one alternative is to use Interlocked.Read and Interlocked.Exchange acting on longs, in conjunction with BitConverter.Int64BitsToDouble and BitConverter.DoubleToInt64Bits. You could encapsulate this within a VolatileDouble struct. (I'd probably make it a struct rather than a class.)

Answer 2

To work as above, you'd need to have it immutable (no setter) - perhaps with some implicit conversion operators for convenience. Otherwise, people could change the value without changing the (volatile) reference.

public class MyThreadedClass
{
    volatile Box<double> volDouble = 123.45;
}

public class Box<T> where T : struct
{
    private readonly T value;
    public Box(T value) { this.value = value; }
    public T Value {get {return value;}}

    // explicit as nulls are a problem...
    public static explicit operator T(Box<T> box) {
        return box.value; }
    public static implicit operator T?(Box<T> box) {
        return box == null ? new T?() : new T?(box.value); }
    public static implicit operator Box<T>(T value) {
        return new Box<T>(value); }
    public static implicit operator Box<T>(T? value) {
        return value.HasValue ? new Box<T>(value.Value) : null; }
}

Beyond that - locking would be the best option.

Answer 3

You're just declaring that the reference is volatile not the instance, so that will not solve the problem.

Answer 4

The volatile documentation is some how misleading...

when the msdn documentation says that it uses the most up to date value what does it mean??? I'm sure that in a simple value this does not lead to confusion, but what about a reference, as Brian Rasmussen you are just talking about the ref not the actual instance (and therefore the interesting data).

From my point of view using volatile is not a good idea and I'd go for the lock, anyway this article might help you: http://www.bluebytesoftware.com/blog/PermaLink,guid,dd3aff8a-7f8d-4de6-a2e7-d199662b68f4.aspx