Thread synchronization and .NET version issues

I’m just doing some tests to see if multithreading can improve the performance of my physics engine add-on.

The code’s core concept does work. However, I’ve been using “poor man’s barriers” so far by creating/joining threads as necessary. I’m amazed that got any performance gains at all, but it did. However, I think I could get even more if I created the threads once and then use a Barrier to synchronize them.

The problem I run into is that, from what I gather, Unity uses version 2.0 of the .NET framework, whereas version 4.0 is where the Barrier first appeared for .NET.

I’ve tried recreating my own version of a barrier. Although functional, it’s horribly inefficient.

So, would there be any way to…

  • have Unity use .NET 4.0 or newer version of .NET
  • use Barriers with .NET 2.0 (or whatever Unity uses)
  • use something like a barrier with .NET 2.0 (or whatever Unity uses) that isn’t just thread creation/joining every cycle

If yes to any of those, how?

Alternatively, if Unity is MEANT to use .NET 4.0 or newer, how can I solve the problem of it not being able to ‘see’ the Barrier class when I include System.Threading?

Bulleted answers your questions:

  • There is no user-accessible way to have Unity use .Net 4.0. We’re stuck on horrible Mono 2.6 until UT decides to spend some resources building an up-to-date version of Mono into their engine. Last time I heard they said they’d try to make it in the 4.0 release cycle, but in truth, there is no set-in-stone promise about when it will happen.
  • There is no way to use Barriers with .Net 2.0 that I know of.
  • Thread synchronization in Unity is accomplished in the “old-fashioned way” with locking mechanisms and blocking. Use the lock keyword to protect shared variables. Use the AutoResetEvent class or the Semaphore class to cause threads to block until signaled to continue. Use the Monitor class to restrict access to objects.