Does a lock around a write guarantee fresh read in another thread? (.Net, memory model)

Question

Say I have a property whose setter is protected by a lock, but without any lock around the getter, e.g.

private long _myField;
public long MyProperty
{
    get { return _myField; }
    set { lock(whatever) _myField = value; }
}

In addition to synchronizing writes (but not reads), the lock, or rather Monitor.Exit, should cause a volatile write. Let's now say we have two threads A and B, and the following sequence happens:

A reads the current value of MyProperty.
B writes a new value to MyProperty.
A reads the current value of MyProperty again.

Q: Is A now guaranteed to see the new value? Or did our lock just ensure that B writes to main memory in a timely manner, but not that other threads read a fresh value? Or could the answer even depend on whether we're running in .Net 2+ or a "weaker" ECMA implementation?

score 3 · Accepted Answer · answered Mar 06 '11 at 05:45

3

No, since the read does not have the explicit memory barrier, it is not "guaranteed" to see the new value.

You can use a ReaderWriterLockSlim to insure that a) the writes lock each other and b) the reads always pickup the new value.

private readonly ReaderWriterLockSlim _myFieldLock = new ReaderWriterLockSlim();
private long _myField;
public long MyProperty
{
    get 
    {
        _myFieldLock.EnterReadLock();
        try
        {
            return _myField;
        }
        finally
        {
            _myFieldLock.ExitReadLock();
        }
    }
    set
    {
        _myFieldLock.EnterWriteLock();
        try
        {
            _myField = value;
        }
        finally
        {
            _myFieldLock.ExitWriteLock();
        }
    }
}

answered Mar 06 '11 at 05:45

The Scrum Meister

29,681
8
66
64

Note: The OP code `value = _myField` looks like a mistake, so i changed it to `_myField = value`. – The Scrum Meister Mar 06 '11 at 05:51
1

What's the point of the RWLS? The lock keyword in the getter and setter will work just as well for two threads, with *lots* less overhead. – Hans Passant Mar 06 '11 at 05:56
@hans-passant What if there are more threads reading at the same time? – The Scrum Meister Mar 06 '11 at 05:56
@hans-passant http://stackoverflow.com/questions/407238/readerwriterlockslim-vs-monitor Don't know if the answer is correct though, Have you experienced better performance with the `lock` vs `ReaderWriterLockSlim`? – The Scrum Meister Mar 06 '11 at 05:57
@scrum - a mistake indeed, fixed. – ehnmark Mar 06 '11 at 09:01

score 1 · Answer 2 · answered Mar 06 '11 at 05:55

1

If you used Interlocked.Read in the getter you should always read the new value. See Threading in C# for more information about memory fences

answered Mar 06 '11 at 05:55

BrandonAGr

5,827
5
47
72

Does a lock around a write guarantee fresh read in another thread? (.Net, memory model)

2 Answers2

Linked