Question

Consider the following code, which takes place in a background thread (“thread B”):

List<T> invocationQueueCopy;
lock (invocationQueue)
{
    invocationQueueCopy = invocationQueue;
    invocationQueue = new List<T>();
}

In another thread (“thread A”) I simply lock “invocationQueue” before adding to it:

lock (invocationQueue)
{
    invocationQueue.Add(args);
}

I have read that reference assignment is atomic, but could it ever occur that “thread A” will end up writing to the old list (the one replaced in “thread B”) after receiving the lock? I have read other answers that imply it could, if the value of the reference were stored in a register on “thread A” then it would not know that “thread B” had modified the value in the class. If this is so, would declaring “invocationQueue” volatile prevent this?

Notes:

• I know I could clone then clear the list.
• I
  know I could have a separate lock
  object for the list.

But I’d rather not do either of these things unless it is required.

Thanks in advance.

Edit:

Just to clarify from Adam’s comments: invocationQueue is a private field which is created internally to this class and never exposed to the outside world so nothing could lock on it except these two methods.

Answer 1

EDIT: Your solution will work. Lock creates a full fence so any caching is prevented, basically meaning you’ll always get the most recent value for the list reference. The only thing, as suggested in the comments is the fact that you should do the locking on a neutral object, not the list itself.

The following is wrong!! But I let it here anyway to show how fu*** hard threading might be… the fact is the following reasoning is defeated by the fact that lock creates a full fence.

Yeah, it can happen so don’t do it
that way.

It won’t get better even if you did
the lock into a readonly whatever
object.

See what might happen (although most
of the time it WON’T happen).

ThreadA and ThreadB are executing on
different processors, each one with
its own cache memory which holds the
reference to incovationQueue.

• ThreadB locks invocationQueue, the lock is done to a reference which is
  taken for the cache of processor1, not
  to a variable name.
• ThreadB copies the invocationQueue.
• ThreadA locks invocationQueue, the lock is done to a reference which is
  taken for the cache on processor2 and
  which, in this moment is the same as
  the one in processor1, and starts
  waiting.
• ThreadB creates a new List and assigns it to the invocationQueue, the
  cache in the processor1 is updated but
  since the variable is NOT volatile
  that’s all that happens.
• ThreadA enters the lock and gets the reference from his cache, which points
  to the old reference, therefore you
  end up adding the variable to the old
  list.

So you need to make the list volatile
AND use the lock if you’re going to be
playing with the reference itself.