Unresolved contention for Intel Fortran RTL global resource

[Dogbite]

As I have slogged forward (I hope) in the process of OMPizing my large legacy program, I have already encountered one of OMP's most endearing traits: the program now crashes multiple times in multiple places in a single run. (Of course, this is progress compared to the program simply stopping without explanation or error message.)

I am hoping someone can provide insight into this particular message beyond what the documentation provides:

forrtl: severe (152) unresolved contention for Intel Fortran RTL global resource

This seems to indicate that the system is having trouble handling multiple calls to IO routines from the individual threads -- that is, the routines are not capable of handling threaded IO calls. This reminds me of something I read about using CRITICAL declarations to isolate IO calls.

I am wondering about the level of granularity I need to use for this protection. Is it sufficient to isolate calls to an individual file, or must Iisolate all IO calls to all files? Or does it depend on the call: do I need to isolate all READ calls from each other and all WRITE calls from each other, but can permit Thread 0 to READ while Thread 3 WRITEs?

And are there other considerations I'm missing?

[jimdempseyatthecove]

In my original response 2) you would use different unit numbers (for different files), critical section not required, However, in alternate method 2nd response 2) (program, open/init, append, append, append, ..., append, close, end program), only one unit required and critical section required.

I should have been clearer (got to read through the lines)

Jim Dempsey

[IanH]

Dogbite wrote:
I just have to ask:  Shouldn't iUnit be assigned a value at some point?  At this point I wouldn't be sure that the two routines are writing to the same file.

The code uses F2008's best-thing-since-sliced-bread NEWUNIT= specifier in the OPEN statement to do that.

[andrew_4619]

@IanH: The code uses F2008's best-thing-since-sliced-bread NEWUNIT= specifier in the OPEN statement to do that. 

+1  Now that is really useful (I never rated sliced bread much though) ....!!!

[onkelhotte]

Yesterday I rewrote my program, now it has an open, a write and a close subroutine like Jim suggested. It was a lot of work because the final close statement could be in many branches in my program, so I tried to avoid that by using a create and an open - write - close subroutine. Now it works, thanks!

But why does the "forrtl: severe (152): unresolved contention for Intel Fortran RTL global resource" error comes up? The open - write - close subroutine is being called every 0.8 to 1 second, that should be enough time for Windows7 to do three simple I/O operations...

The NEWUNIT specifier is simple and a great way to handle I/O operations. That´s more than just +1 :-)

Markus

[jimdempseyatthecove]

I think that this is a Windows related quirk. I will restrict myself from saying error, because I am certain MS will say it is not an error. Some background on my suspicions.

I have a utility program written in C++ back in 1997 that is used to synchronize paths. When the destination path is empty, it becomes a copy. Prior to Windows 7 the synchronization to empty folder across a network path would always work.  Since Windows 7 some of the files would fail to copy (or delete and copy when target file out of date), thus requiring a subsequent synchronization. Upon examination of the problem, the "error" codes returned are not "hard errors" (e.g. file in use) but fall into the soft error category such as: insufficient resources. The problem would occur less frequently with synchronizations using local disks.The MSDN articles tend to say something like: When receiving 0x.... retry the operation.

My guess is: IVF is receiving one of these soft errors (one that MS suggests immediate retry), and instead of retrying IFV hard errors out (unresolved...RTL global resource").

A reproducer might be handy for Intel to investigate this problem. Your init routine, writeReportTemperatures, and a loop to write ~1GB of data, plus a dummy module that declares the variables used. Submit with details (IVF version, O/S version, IVF options, placement of output file loca/remote/type).

The work-arround I proffered reduces the probability of this error.

Happy for you to get working...

Jim Dempsey