10

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; }
}
johnc
  • 39,385
  • 37
  • 101
  • 139

5 Answers5

18

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.)

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • Kind of suspected that only the reference was volatile, hence the question. Thanks for the confirmation – johnc Feb 10 '09 at 10:48
  • if he made sure the VolatileDouble is immutable he shouldn't have problems, correct? – Jonathan C Dickinson Feb 10 '09 at 10:51
  • Thanks also for the Interlocked and BitConverter suggestions, sparked a whole new path of thought – johnc Feb 10 '09 at 10:57
  • @Jonathan: Yes, I *believe* it would be okay in that case - at least using the .NET 2.0 memory model which is slightly stronger than the ECMA memory model. – Jon Skeet Feb 10 '09 at 11:02
  • Sorry for coming late to the party, but it is actually inherently a C# specification which states that atomic reads/writes are guaranteed only on types of size 4 or less. CIL makes stronger guarantee of atomic r/w on sizes of a pointer or smaller (i.e. 4 bytes on x86, 8 bytes on x86_64 (looking at you, double)). The compiler compiles from C# to CIL, so it can't know what the processor will be. The last piece of the puzzle is that only types that have guaranteed atomic r/w ops can be delcared volatile. – Ordoshsen May 12 '20 at 23:18
5

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.

Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900
3

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

Brian Rasmussen
  • 114,645
  • 34
  • 221
  • 317
0

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

mandel
  • 2,921
  • 3
  • 23
  • 27
-1

You cannot make a volatile long or double (64 bits) but you can make a volatile int (32 bits) and by using two 32 bit ints you can successfully use bit manipulation to simulate 64 bits (tested and working):

public class VolatileLong
{
    private readonly object lockObj = new object();
    private volatile int lo32;
    private volatile int hi32;
    public long Value
    {
        get
        {
            lock (lockObj)
            {
                return ((long)hi32 << 32) | ((long)lo32 & 0xFFFFFFFFL);
            }
        }
        set
        {
            lock (lockObj)
            {
                lo32 = (int)(value & 0xFFFFFFFFL);
                hi32 = (int)((value - ((long)lo32 & 0xFFFFFFFFL)) >> 32);
            }
        }
    }
}

public class VolatileDouble
{
    private readonly VolatileLong vl = new VolatileLong();
    public double Value
    {
        get
        {
            return System.BitConverter.Int64BitsToDouble(vl.Value);
        }
        set
        {
            vl.Value = System.BitConverter.DoubleToInt64Bits(value);
        }
    }
}
sahlaysta
  • 95
  • 1
  • 3