Using AppDomains to Parallelize Non-thread-safe DL

Question

I have an unmanaged C++ DLL that my .NET application uses via p/invoke. The method that I need from this DLL is fairly time consuming and I would like to parallelize the method calls. The problem is that it uses a bunch of statics and globals, so it is not thread-safe (and can't be changed). My plan was to overcome this non-thread-safe issue by calling the unmanaged DLL from multiple AppDomains in parallel.

I can call the unmanaged code from the multiple AppDomains without any problems as long as I don't do it in parallel, but as soon as I make the calls in parallel, I get an AccessViolationException. I am using Parallel.For() to make the parallel calls.

Is it possible to make a non-thread-safe unmanaged DLL "thread-safe" by simply making the calls from multiple AppDomains?

Answer 1

Calling the native method from multiple AppDomain instances won't help you at all here. AppDomain boundaries don't apply to native DLL's and they won't provide any benefit

Answer 2

First and foremost: Load multiple copies of dll in same process

You'd have to make sure that all invocations within an AppDomain are on a single thread.

ParallelFor cannot make that happen, so you'd need to

• manually parallelize (chunk up your loop for each thread/appdomain)
• better (IMHO): write a wrapper function that will use a specific instance of your native dll (e.g. by using a reference to the AppDomain from threadlocal storage?).

Note that depending on the complexity of your situation (callbacks, use of global data in managed library) you might want to limit execution of each AppDomain to a specific CPU core (core affinity: see Begin/EndThreadAffinity). I might be a tad paranoid here :)

Answer 3

Wrap the C++ DLL in an EXE and parallelize process invocations (instead of running this code in threads or AppDomains). I had this problem with GeckoFX, which doesn't like threads, and this solution worked just fine. Of course, it's up to you to manage communication with these processes. I blogged about this some time ago.