On Apr 15 2011, Tobias Burnus wrote:
(Frankly, I am not 100% sure about the exact semantics of ASYNCHRONOUS; I think might be implemented by preventing all code movements which involve swapping an ASYNCHRONOUS variable with a function call, which is not pure. Otherwise, in terms of the variable value, it acts like a normal variable, i.e. if one does: "a = 7" and does not set "a" afterwards (assignment or via function calls), it remains 7. The changing of the variable is explicit - even if it only becomes effective with some delay.)
I am, but I am not sure how to describe them. The relevant constraints on the program are in Fortran 2008 9.6.4.1 paras 5 and 6 (page 220), and here is roughly what it means for the compiler. The ASYNCHRONOUS attribute says that a variable may be used for such purposes, and therefore can be changed unpredictably (if writable) or referenced unpredictably, at any point while it is 'active' for asynchronous I/O (i.e. it is a pending input-output sequence affector, a term that I find bizarre). It is a bit like the intent of VOLATILE, in that respect only. But it also says: 1) The program may not change it if it is liable to be referenced, or reference it if it is liable to be changed. But this applies ONLY during those windows of vulnerability. 2) A window of vulnerability can be changed only by explicit action, either an asynchronous I/O statement or calling a procedure that has access to that variable. Note that closing the window doesn't need explicit access, as it operates on just a 'transfer token', but that is as if the action that opened the window squirreled away a pointer to the array when it started the asynchronous I/O. This means that, if a compiler can determine that code is NOT in a window of vulnerability, all normal optimisations can be applied. And, if the window is for reference only, reference to the variable and taking a copy is allowed. For example, if there is an assignment statement to it or it is passed as an argument to a procedure without ASYNCHRONOUS or INTENT(IN), the compiler can tell that there is no I/O in progress at that point. Similarly, if it is referenced or passed to a procedure without ASYNCHRONOUS but with INTENT(IN), it may be being referenced but won't be being changed (asynchronously). Of course, that may not be the case. But, if it isn't, the program is broken, and the behaviour is undefined - so what the hell? And I apologise about my English :-) I don't have time just now to rephrase it in less arcane usage, and am aware that it is tricky. Regards, Nick Maclaren.
