openMP with DFORRT.DLL

[Rudy__Delcroit]

Hello,

I'm investigating the usage of openMP for one of our programs. This program calls a DLL which has been written in Fortran CVF and requires DFORRT.DLL.

However on my early tests,my programcrashes with error 40 - Recursive I/O Operation in DFORRT.DLL.

Reading in the forum, the solution is to compile for multithread.

My program has this option however, I suspect the DLL not to have it and I have no means to recompile it.

Can I simply forget about doing multithread on my application ?

Regards,
Vincent

[jimdempseyatthecove]

>>Can I simply forget about doing multithread on my application ?

If you can identify the routines you call to DFORRT.DLL, try placing the calls within and OpenMP critical section

!$OMP CRITICAL (YourNameForCriticalDFORRT)
CALL TheRoutineInDFORRT(...)
!$OMP END CRITICAL (YourNameForCriticalDFORRT)

Jim Dempsey

[Rudy__Delcroit]

That's an idea but this subroutine represent 95% of the CPU time.If I put a critical section, all the other thread will basicly wait or worst spend time to synchronize. It wouldhave dream to run several instance of this routine in parallel.

Anyotherthough ?

[Steven_L_Intel1]

There isn't any other way to fix this. You can't start an I/O operation on a unit while another one is already in progress for that unit - that's a language restriction and is enforced by the run-time library. (There is an exception for internal I/O.) You will have to serialize calls to this library routine that does I/O.

[jimdempseyatthecove]

The I/O call that generated the error message is but one of your problems.

It is entirely possible, most likely highly probable, that you have calls to DFORRT.DLL that are not I/O and have no check for reentrancy (the Fortran error message called the recursive).

For subroutines and functions that have temporaries that are SAVE (implicit or explicit), these will (may) generate erronious results when concurrently called. Note, scalars not attributed SAVE tend to be stack. Arrays not attributed SAVE may be save or stack, this was an implimentation issue.

You may need to replace the functionality of DFORRT.DLL. At least for the heavily called routines.

Jim Dempsey

[Steven_L_Intel1]

DFORRT.DLL isn't the problem - it's the Fortran source code in the CVF-compiled DLL that is not thread-safe.

[jimdempseyatthecove]

I agree. However the user does not have the source code and cannot recompile the DLL. The problem is with the DLL (as-was compiled and delivered). To the user the problem is in the DLL (on-hand).

I imagine that Intel is in possession of the original source code and could potentially produce a DFORRTmp.DLL. Though I think it would be better for the user to create a shell that uses the current library but with a shell DLL who's functions that have the same names and arguments as in DFORRT.DLL (at least for the functions and subroutines used in the user's applicaiton). This might not be as large of a project as with parallizing a large application.

Jim Dempsey

[Steven_L_Intel1]

Even if we could do that, it would not help. DFORRT.DLL is not the problem. The code in the user's DLL is not thread-safe - it will allow multiple threads to start an I/O operation on the same unit at the same time. That will be an error, whether the RTL is thread-safe or not.

If it is not possible to modify the sources of the DLL then serialization of calls using a mutex is the only way.