When to link with 'Multithreaded' run-time library

[tom_c_lin]

A general question about how to select runtime library. I have a program which, periodically during its execution, will call system to start another one or two programs. DoI need to compile/link this program with'Multi-threaded'library?Can someone give me general rules when to use Single-threaded or Multi-threaded libraries? Thanks in advance. Have a great day.

Tom Lin

[Steven_L_Intel1]

Calls to SYSTEM don't create new threads. The multithread library is for when your application creates threads. But you may as well start using the multithread library anyway as VS2005 eliminates the static, single-thread libraries.

[tom_c_lin]

Steve, Thank you for the answer. Is there any difference (even my program does not generate any thread)in linking with Single-threaded library or Multi-threaded library? Do I need to re-compile and re-link allthe static libraries (or DLL) (used by this program)with Multi-threaded runtime library too? Thanks.

Tom Lin

[Steven_L_Intel1]

All your Fortran code should be compiled with the same option, otherwise you'll get errors at link time. If you are building Fortran DLLs and using them from Fortran code, be sure to choose the same library option for your executables that you use for the DLL, which defaults to "DLL".

[pjh_gn]

Presumably calling a single threaded DLL from a multithreaded main program is OK provided I link at runtime with Windows API calls?

[Jugoslav_Dujic]

How you link with Windows API calls is irrelevant. The point in question is that, with different run-time libraries, you end up having two copies of RTL's in address space, each having a separate set of memory and unit and buffer states.

However, Steve and I (kind of) disagree about the consequences. Apart from wasting some address space, I maintain that having two copies of RTL is fairly harmless, as long as you don't try to mix the usages, for example:

*ALLOCATEing a POINTER in .exe and trying to DEALLOCATE it in the .dll (since two RTLs have different memory managers)
*OPENing unit 42 in .exe and READing from unit 42 in the dll.(since two RTLs have different file buffer and state information)

Since such usages are fairly rare, I think that using different RTLs is generally OK. I'm not sure if the Steve's (and documentation) recommendation of using the same DLL RTL is just for the sake of "being on the safe side", or there are more issues that I don't see.

[Steven_L_Intel1]

Actually, I agree with Jugoslav that it is harmless in most cases. But I generally warn against having multiple DLLs because I have seen customers complain of problems such as those Jugoslav mentions. As long as you don't try to share resources across the RTLs, you'll generally be fine.

As it happens, I've been tasked with writing a more detailed explanation of this matter for our next release. Not for the "two Fortran DLLs", but for "two MSVC DLLs", which you'll almost certainly have if you use the DLL form of the Fortran run-time library. Here, it's much harder to run into a problem but I can think of ways it can happen (use the Fortran intrinsic malloc and then call C code that tries to free it, for example.)

[jimdempseyatthecove]

It is not wise to make that assumption.

Example: If a routine in the single threaded DLL was written in FORTRAN and if the routine contains something like:

real :: VectorA(3)

instead of:

real, automatic :: VectorA(3)

Then in the first occurance there will be a static array in the scope of the routine. This means there is but one set of memory addresses for VectorA. If two threads call the same routine at the same time then their use of VectorA is not exclusive (trashes results).

In the second occurance (atomatic) or from a multi-threaded DLL the local storage arrays are assumed (required) to be on the stack unless explicitly stated otherwise. If two threads call the same routine at the same time their use of VectorA is exclusive (does not trash results). This is due to the fact that each thread has its own instance of VectorA.

I believe the converse of your statement is true: Calling a multithreaded DLL from a single threaded EXE is OK. But this can have its own problems too. Such as if the multithreaded DLL assumes the thread libraries (OpenMP) have been initiated by the EXE.

There are:

multi-thread safe libraries
and
multi-threaded - multi-thread libraries (spawns threads for own use)

Your best bet is to link with the proper library.

Jim Dempsey