CODEWITHSUNDEEP
.netmultithreadingloadlibrary
Euan
Euan

Reputation: 63

Load Dll multiple times to allow multi threading in .Net

My .Net program uses a fortran Dll to perform a maths function (Arpack, solves eigen modes). I believe the fortran contains static varibles and generally isn't thread safe. Also it's very complicated and would probably take a lot of hard work to make it thread safe. The Dll isn't very large (700K) so I just want to load it many times (say 4, or maybe 8) to allow the threads to work concurrently. Anyone have any idea how I can do this? I hear that LoadLibrary will always return the same handle when called multiple times. So, as it stands my only solution is to have multiple copies of my Dll on disk (Arpack1.dll, Arpack2.dll etc) and load them as required. Pretty horrible.

Any ideas?

Euan

Upvotes: 6

Views: 5761

Answers (3)

Hans Passant
Hans Passant

Reputation: 942448

The workaround you found is actually a pretty decent one. There might be small odds that LoadLibraryEx() with the LOAD_LIBRARY_AS_IMAGE_RESOURCE option will work. That option allows you to load it multiple times. I seriously doubt it though, the DLL almost certainly relies on getting its runtime support code initialized through DllMain.

One thing I didn't hear you mention is the pain of having to use GetProcAddress(). Make sure you do or you'll still stomp global variables when you start threading. Each thread must use its own address.

Upvotes: 2

Dominik Fretz
Dominik Fretz

Reputation: 1378

As you figuered out, you cannot load the library multiple times. I guess you have two possibilities:

In both solutions you need to consider a method of data exchange betwen the processes/app domains. Anyway, it won't be a simple task!

Upvotes: 1

Cheeso
Cheeso

Reputation: 192657

Loading the DLL is not the way to create a thread. Your two options are to use AppDomains or outright separate processes.

The easy way to do it might be to simply use a master/slave arrangement, where the logic that uses the library is all done in the slave process. The master kicks off as many "slaves" as it wants or needs, and then collects the return values.

Write the code in the "slave" as if it is single threaded, because... it is.

Use System.Diagnostics.Process.Start from the master, to launch these things.

In general, copying the DLL and loading all the copies is not a failsafe approach; the DLLs themselves may access OS resources like mutexes or even lockfiles. These won't be aware that the copies are supposed to be "separate".

If your library is purely a compute library and you REALLY REALLY want to do the copy-and-load-the-copies approach, you can create hardlinks to avoid having to duplicate the actual DLL file. (fsutil hardlink create on Win7 or Vista)

Upvotes: 2

Related Questions