Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28381 Discussions

Asynchronous IO IOSTAT=x IOMSG=y lifetime

jimdempseyatthecove
Honored Contributor III
402 Views

On Asynchronous I/O, are the results of IOSTAT and/or IOMSG returned asynchronously (when the I/O completes) or at the point of READ/WRITE? 

IOW is there a lifetime requirement of the target variables to be available during the lifetime of the I/O?

 

Jim Dempsey

0 Kudos
5 Replies
IanH
Honored Contributor II
385 Views

Definition of the variables nominated by IOSTAT or IOMSG happens during the execution of the relevant statement with the IOSTAT or IOMSG specifier, not "in between" the statements that initiate and wait on transfers.  Unlike the items in the input/output list, there is no requirement on the lifetime of the variables specified by IOSTAT or IOMSG.  See F2018 12.6.4.1p7 in particular.

jimdempseyatthecove
Honored Contributor III
368 Views

The reason I ask is from observance

subroutine A
  ...
  call B
              subroutine B
                ...
                character(len=256) :: ioMSG
                integer :: ioStat
                ...
             read(inUnit, ASYNCHRONOUS='YES', END=100, ERR=200, IOMSG=ioMSG, IOSTAT=ioStat) array
             return
         100 call DOSTOP("END myReadTemp"//ioMSG)
         200 call DOSTOP("ERR myReadTemp"//ioMSG)
             end subroutine B
    ...(back in A)
  wait(inUnit)
! stack occasionaly gets corrupted

The particular problem (stack check reports corruption) occurs when subroutine A is within a parallel region (and as a result B is executing within a parallel region). My (unfounded) assumption is the read is storing the addresses of ioMSG and ioStat for potential future use upon I/O completion. IIF that is the case, then the stack would get corrupted (as B goes out of scope prior to I/O completion).

This problem is intermittent. When running with OMP_NUM_THREADS=1, the problem does not appear. If I vary the amount of stack, the problem moves around.

I am aware that I can obtain at wait(u) as well as via INQUIRE. 

Now then, I moved the ioMSG and ioStat to within a module data space and this resolved the stack corruption issue.

Note, this is not stack overflow, rather in debug mode, chkstk is called to check signature bytes surrounding the stack frame. These get (got) clobbered.

Jim Dempsey

0 Kudos
IanH
Honored Contributor II
353 Views

There's always the possibility of compiler/runtime issues, but it is a bit hard to say from code fragments.  Plenty of opportunity for programmer error within the combination of OpenMP and asynchronous I/O too.

0 Kudos
Steve_Lionel
Honored Contributor III
376 Views

If you want to know the status after the asynch operation has completed, that is available from the WAIT statement.

0 Kudos
jimdempseyatthecove
Honored Contributor III
318 Views

>>Plenty of opportunity for programmer error

Been there many of times. Definitely could be the problem.

 

Jim

 

 

0 Kudos
Reply