Concurrent changes on non-concurrent collections

I don’t do it on purpose but sometimes it can be so much fun to dive into an exception you’ve never seen before. You always come out with some new acquired wisdom.

It all started with the following exception during the execution of our unit tests:

System.InvalidOperationException : Operations that change non-concurrent collections must have exclusive access. A concurrent update was performed on this collection and corrupted its state. The collection's state is no longer correct.

A look at the stacktrace brought us to the initialization system of our application where multiple modules are configured and initialized:

at System.Collections.Generic.Dictionary`2.TryInsert(TKey key, TValue value, InsertionBehavior behavior)

 at System.Collections.Generic.Dictionary`2.set_Item(TKey key, TValue value)

 at SOFACore.EntityFramework.EntityFrameworkModule.Initialize(IServiceCollection services) in /_/SOFACore/SOFACore.EntityFramework/EntityFrameworkModule.cs:line 30

Inside this module we copy some data over from the configuration system to a static list:

During normal execution this never gives an error as the initialization only run once during the startup of our application. However during testing we run multiple tests in parallel and the initialization is executed multiple times and each execution mutates a shared static Dictionary.

How to fix this?

There are multiple possible ways to fix this:

A first option is to make it thread-safe:

• We can guard updates with a lock around the write.
• Or replace the static dictionary with a ConcurrentDictionary<string, Type> (or an immutable dictionary assigned atomically).

A second option is to refactor to remove the global mutable state:

• This can be done by avoiding the static registry; I could keep the mapping in DI (e.g., register an IDbContextTypeRegistry as a singleton, or bind via IOptions<EntityFrameworkConfiguration>).

Or if we are really lazy, we can make the tests run this part sequentially:

• Therefore I could disable xUnit parallelization for this assembly: add [assembly: CollectionBehavior(DisableTestParallelization = true)].
• Or place all affected tests in the same [Collection("EF Module")] to serialize them while keeping other tests parallel.

As a quick fix, we decided to add a lock around the write and created a ticket on the backlog (that we could assign to the Github Copilot Agent) to remove the global state and use the DI container to handle this.

The lock type

We used the new Lock type introduced in .NET 9. This type is a dedicated lock object with enhanced semantics. Under the hood, the compiler rewrites your code to an optimized version that is using  Lock.EnterScope():

Remark: Depending on your use case, this can be about ~25% faster than traditional object-based locking. So that is a nice improvement for a small change.

More information

The lock statement - synchronize access to shared resources - C# reference | Microsoft Learn