Question

Is an atomic read guaranteed when you mix Interlocked operations with lock() (and other higher-level locks)?

I am interested in general behaviour when mixing locking mechanisms like this, and any differences between Int32 and Int64.

private Int64 count;
private object _myLock;

public Int64 Count 
{
  get 
  {
    lock(_myLock)
    {
      return count;
    }
  }
}

public void Increment
{
  Interlocked.Increment(ref count);
}

Answer 1

Note: This answer (including the two edits already) was given before the question was changed to have a long count. For the current question instead of Thread.VolatileRead I would use Interlocked.Read, which also has volatile semantics and would also deal with the 64-bit read issue discussed here and introduced into the question

An atomic read is guaranteed without locking, because reads of properly-aligned values of 32-bit or less, which your count is, are guaranteed to be atomic.

This differs from a 64-bit value where if it started at -1, and was read while another thread was incrementing it, could result in the value read being -1 (happened before increment), 0 (happened after increment) or either of 4294967295 or -4294967296 (32 bits written to 0, other 32bits awaiting write).

The atomic increment of Interlocked.Increment means that the whole increment operation is atomic. Consider that increment is conceptually:

1. Read the value.
2. Add one to the value.
3. Write the value.

Then if x is 54 and one thread tries to increment it while another tries to set it to 67, the two correct possible values are 67 (increment happens first, then is written over) or 68 (assignment happens first, then is incremented) but non-atomic increment can result in 55 (increment reads, assignment of 67 happens, increment writes).

A more common real case is x is 54 and one thread increments and another decrements. Here the only valid result is 54 (one up, then one down, or vice-versa), but if not atomic then possible results are 53, 54 and 55.

If you just want a count that is incremented atomically, the correct code is:

private int count;

public int Count 
{
  get 
  {
    return Thread.VolatileRead(byref count);
  }
}

public void Increment
{
  Interlocked.Increment(count);
}

If however you want to act upon that count, then it will need stronger locking. This is because the thread using the count can become out of date before its operation is finished. In this case you need to lock on everything that cares about the count and everything that changes it. Just how this need be done (and whether its even important to do at all) depends on more matters of your use-case than can be inferred from your question.

Edit: Oh, you may want to lock simply to force a memory barrier. You may also want to change Count‘s implementation to return Thread.VolatileRead(ref count); to make sure CPU caches are flushed if you are going to remove the lock. It depends on how important cache staleness is in this case. (Another alternative is to make count volatile, as then all reads and writes will be volatile. Note that this isn’t needed for the Interlocked operations as they are always volatile.)

Edit 2: Indeed, you’re so likely to want this volatile read, that I’m changing the answer above. It is possible you won’t care about what it offers, but much less likely.