- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If you want to know the status after the asynch operation has completed, that is available from the WAIT statement.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>>Plenty of opportunity for programmer error
Been there many of times. Definitely could be the problem.
Jim

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page