Threading and DllImport

[Seth Gecko]

Hi

I am developing a complex VB.Net Windows application for an
engineering firm (don't ask me why they prefer VB.Net...). All the
engineering calculations are done in FORTRAN which is compiled to a
non COM type DLL (meaning you can't create an Interop for it). This is
called from within the .Net application using DllImport, just like
using a Windows API call. This works fine.
The problem arises when we create threads (using BeginInvoke) and each
thread is calling the same DllImported function. This results in
various unpredictable errors from within the FORTRAN code, most likely
because the FORTRAN function (and its memory) is shared between
threads. The FORTRAN function itself is thread safe (checked using
Intel Thread-Checker), but my guess is that when using DllImport the
function is loaded into the application process (as opposed to the
thread) and thereby becomes shared.
If I put a SyncLock around the DllImported function call everything
works again, but this means only one thread at a time is allowed to do
the actual calculation which was not intended when we introduced
multiple threads.

Is there any way to solve this problem? My initial suggestion was to
avoid using DllImport and instead try to create some sort of instance
of the FORTRAN function; one unique instance for each thread so that
the FORTRAN code does not share memory between threads. I haven't been
able to achieve this and I am not sure that it is even possible or
that it would actually solve the problem. Any suggestions would be
greatly appreciated...

Thanks
....Casper Lafrenz

 

[Benny Skjold Tordrup]

Is your application marked STAThread or MTAThread (don'n know if it makes a
difference))

Best regards,

Benny