Hi Davy,

Good article. Just one comment: I’d be careful with code like this:

public virtual T FindFirst(Func expression)
{
lock (Monitor)
{
return Members.Values.FirstOrDefault(expression);
}
}

Holding a lock whilst calling into user-supplied code can be dangerous. They may call out to a function that also acquires a lock, but that lock may be held by another thread waiting for the results of another query on your repository (that shares the same monitor).

Let me give an example:
“Background Synchronizer” thread holds lock on Synchronizer, calls CustomerRepository.FindAll(…) [holding Synchronizer.Monitor, requesting Repository.Monitor]

“UI” thread performs search; calls CustomerRepository.FindAll(callback). The callback makes use of the Synchronizer [holding Repository.Monitor, requesting Synchronizer.Monitor]

What you end up with is a classic “has A, needs B” while “has B, needs A” deadlock scenario. But your code only controls one of the locks, and their code controls another. Avoiding deadlocks isn’t as simple as avoiding lock B->lock A in your own class.

My preference is to take a snapshot of the objects to process whilst in the lock, and to process them outside of the lock:

public virtual T FindFirst(Func expression)
{
List snapshot = new List();
lock (Monitor)
{
snapshot.AddRange(Members.Values);
}
return snapshot.FirstOrDefault(expression)
}

Though it may hit problems with a big collection. A more efficient approach is a snapshot invalidation system where you keep your snapshot around until it is invalidated rather than building it every time.

Alternatively in this case you may be able to avoid the lock completely – though sometimes it’s unavoidable (saving things, for example).

It’s also why I sometimes prefer to use Monitor.TryEnter(lock, timeout) – you avoid deadlocks but suffer/have to plan for exceptions instead. At least you don’t run the risk of tying up every thread in the threadpool.