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)
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…