Migrate a single threaded app to multi-threaded, parallel execution, monte carlo simulation

Question

I\'ve been tasked with taking an existing single threaded monte carlo simulation and optimising it. This is a c# console app, no db access it l

Answer 1

List is definitely not thread-safe. See the section "thread safety" in the System.Collections.Generic.List documentation. The reason is performance: adding thread safety is not free.

Your random number implementation also isn't thread-safe; getting the same numbers multiple times is exactly what you'd expect in this case. Let's use the following simplified model of rnd.NextUniform() to understand what is happening:

1. calculate pseudo-random number from the current state of the object
2. update state of the object so the next call yields a different number
3. return the pseudo-random number

Now, if two threads execute this method in parallel, something like this may happen:

• Thread A calculates a random number as in step 1.
• Thread B calculates a random number as in step 1. Thread A has not yet updated the state of the object, so the result is the same.
• Thread A updates the state of the object as in step 2.
• Thread B updates the state of the object as in step 2, trampling over A's state changes or maybe giving the same result.

As you can see, any reasoning you can do to prove that rnd.NextUniform() works is no longer valid because two threads are interfering with each other. Worse, bugs like this depend on timing and may appear only rarely as "glitches" under certain workloads or on certain systems. Debugging nightmare!

One possible solution is to eliminate the state sharing: give each task its own random number generator initialized with another seed (assuming that instances are not sharing state through static fields in some way).

Another (inferior) solution is to create a field holding a lock object in your MersenneTwister class like this:

private object lockObject = new object();

Then use this lock in your MersenneTwister.NextUniform() implementation:

public double NextUniform()
{
   lock(lockObject)
   {
      // original code here
   }
}

This will prevent two threads from executing the NextUniform() method in parallel. The problem with the list in your Parallel.For can be addressed in a similar manner: separate the Simulate call and the AddRange call, and then add locking around the AddRange call.

My recommendation: avoid sharing any mutable state (like the RNG state) between parallel tasks if at all possible. If no mutable state is shared, no threading issues occur. This also avoids locking bottlenecks: you don't want your "parallel" tasks to wait on a single random number generator that doesn't work in parallel at all. Especially if 30% of the time is spend acquiring random numbers.

Limit state sharing and locking to places where you can't avoid it, like when aggregating the results of parallel execution (as in your AddRange calls).