Does lock() makes sense here?

Question

I have a simple class like :

  public class XXX
  {
    double val1;
    double val2;
    double delta;
    public void SetValues(double v1, double v2)
    {
      val1 = v1;
      val2 = v2;
      delta = val1 - val2;
    }

    public double Val1 { get { return val1; } }
    public double Val2 { get { return val2; } }
    public double Delta { get { return delta; } }
  }

, one thread for setting values and multiple threads that read the values. So one can use lock() to make all read and writes uninterrupted. But I am aware that synchronization is never achived, there is always a chance that Val1 - Val2 may not be equal to Delta which I do not care so much. My concern is more about obtaining the stable values via getters. However lock() is expensive for this situation because mostly the readers will work.

The next best thing that come to my mind is using Interlocked.Exchange()

    public void SetValues(double v1, double v2)
    {
      Interlocked.Exchange(ref val1, v1);
      Interlocked.Exchange(ref val2, v2);
      Interlocked.Exchange(ref delta, v1 - v2);
    }

    public double Val1 { 
      get 
      {
        double val = 0;
        Interlocked.Exchange(ref val, val1);
        return val; 
      } 
    }

But the code seems pretty dum to me. I don't know.

So does lock() makes sense? Should I use the Interlocked.Exchange() for performance gain? Or what else can I do?

Answer 1

For multiple readers / writers scenarios I would use ReaderWriterLockSlim.

Represents a lock that is used to manage access to a resource, 
allowing multiple threads for reading or exclusive access for writing.

Use ReaderWriterLockSlim to protect a resource that is read by multiple 
threads and written to by one thread at a time. ReaderWriterLockSlim 
allows multiple threads to be in read mode, allows one thread to be in 
write mode with exclusive ownership of the lock, and allows one thread 
that has read access to be in upgradeable read mode, from which the 
thread can upgrade to write mode without having to relinquish its 
read access to the resource.