Multi-threaded and THREAD-SAFE DLLs - how to create and test?

[FortranFan]

I have some legacy Fortran 77 code that uses a lot of global data (COMMON blocks, etc.) and which I need to package into a Windows DLL for use in various environments including Microsoft Excel, webservices, etc.  That is, different types of programs will be calling the exported subroutines in this DLL for various calculations.  The subroutines are currently structured such that the arguments are limited to only those variables that makes sense for callers to modify and to those calculation results that callers actually need.  Also, significant amount of data are held in COMMON blocks that get the appropriate values when an initialization subroutine is invoked.  These data are then reused repeatedly during the actual calculations.

I need to ensure the DLL is multi-threaded as well as thread-safe.  How do I go about creating and fully validating such a DLL?  What are the basic elements?  Will I need to restructure the code so that calculations do not depend on any global data?  What is the best approach to learn about threading and thread-safety?  I couldn't find much in Intel Fortran 2013 Help.  I see Intel advertises its Math Kernel Library as multi-threaded and thread-safe; so is IMSL.  I'd like my library to be in the same state.

I'm currently using Compaq Visual Fortran 6.6C with Microsoft Visual Studio 6.0 but I plan to switch to Intel Fortran Composer 2013 with Visual Studio 2010.  Using Compaq Fortran and Visual Studio 6.0, I've created a "single-threaded DLL" that works well with a single-threaded executable such as a Fortran or C main program.   But as expected, the DLL fails when used in a multi-threaded environment such as a C# executable (a .NET application calling the DLL via PInvoke) that deliberately spawns different threads.  Next I'll try using Intel Fortran Composer 2013 with Visual Studio 2010, but it will be good to be knowledgeable about this instead of going in blindly.

Thank you. 

[Steven_L_Intel1]

To verify that the code is effectively using threading, run it under Intel VTune Amplifier XE and look at the thread behavior display, along with locks and waits. To verify correctness, run under Intel Inspector XE's threading checker.

Intel MKL is indeed thread-safe and it takes maximum advantage of threading. IMSL is partially thread-safe and uses Intel MKL in places to provide multithreading.

[FortranFan]

Steve,

Thanks much for your suggestions.

Would you have any comments on the current code structure itself?  Does the use of global data (as I described in my original posting) look inconsistent with how a multi-threaded library is supposed to be structured?  Are there some basic software design and architecture aspects that I should follow to ensure thread-safety?

Is there any information available on what Intel had to do to make MKL thread-safe that we all can learn from?

Thanks again,

[Steven_L_Intel1]

There are others on this forum who have far more experience with writing multithreaded code than I. I will comment that use of COMMON or any other static state can be problematic if you don't handle it properly. Intel Inspector XE can notice these problems and alert you.  The Static Analysis feature of Intel Visual Fortran Studio XE can identify some of these problems at build time.

You need to learn about thread-local storage -and the concept of thread-local COMMON does exist. There are also many books on parallel programming, including some from Intel Press, that may not use Fortran examples but the concepts are universal.