Question

This is a follow-up to a previous question regarding locking on two List(Of T) objects. The answer there was helpful but left me with another question.

Suppose I have a function like this:

Public Function ListWork() As Integer
  List1.Clear()
  ..Some other work which does not modify List1..
  List1.AddRange(SomeArray)
  ..Some more work that does not involve List1..
  Return List1.Count
End Function

which resides in a class that declares List1. In a multithreaded environment, I now understand that I should have a private locking object for List1 and lock List1 whenever it’s modified or enumerated. My question is, should I do this:

Private List1Lock As New Object
Public Function ListWork() As Integer
  SyncLock List1Lock
    List1.Clear()
  End SyncLock
  ..Some other work which does not modify List1..
  SyncLock List1Lock
    List1.AddRange(SomeArray)
  End SyncLock
  ..Some more work that does not involve List1..
  SyncLock List1Lock
    Dim list1Count As Integer = List1.Count
  End SyncLock
  Return list1Count
End Function

or this:

Private List1Lock As New Object
Public Function ListWork() As Integer
  SyncLock List1Lock
    List1.Clear()
    ..Some other work which does not modify List1..
    List1.AddRange(SomeArray)
    ..Some more work that does not involve List1..
    Dim list1Count As Integer = List1.Count
  End SyncLock
  Return list1Count
End Function

I’m guessing that the former example is optimal?

Answer 1

From the examples, it’s hard to tell which one is correct, if either is. A few guidelines/observations though that might help you answer your question, or know what to provide for additional information:

First things first, do you have to synchronize? Would it make more sense for each thread to have an instance of this class? If each instance is local to the thread, and is only modified and used on that thread, you don’t need locking.

If the purpose of this class and utilizing threads is for parallel processing of a larger data set, it might make more sense for the main thread to divide up the task in some logical way, and then wait for the worker threads to complete. In this case, instead of managing threads on your own, look into the ThreadPool and wait handles. Most of the dirty work is done for you then.

About synchronization/locking in general: If your operation was interrupted between steps, would the data be consistent/valid?

In your example, say you have two threads. The first is in the area between .AddRange() and .Count, when the second thread comes along enters the function, and acquires the lock on the list.

Thread 1 runs a bit more, and hits the lock guarding the .Count method, and goes to sleep. Thread 2 in the meantime clears the list and then releases its lock, waking Thread 1 up, which then acquires the lock.

In this case, Thread 1 will have 0 returned from this function, when work was done by thread 1 to build the list. And then, the list length won’t really be 0, since thread 2 has come along and filled the list.

In this case, the locks around the individual list operations break the program, so it makes more sense to have one lock surrounding between Clear and the Count call.

In short, multi-threading is a good way to introduce a whole class of subtle bugs relating to Race Conditions, that often result in Heisenbugs.

It is often wise to avoid threads when you can. If you can’t, try to arrange your workload in ways that require minimal synchronization (e.g. giving the thread a set of data at the start, then waiting for it to signal completion, such as with the thread pool example linked). If you can’t do that, then tread carefully, and always ask yourself “What will happen if two threads run in this area”.

Hopefully this helps arm you for future adventures in multi-threaded code.