[MPI3 Fortran] Proposed solution for the volatile buffer problem

[Bill Long]

N.M. Maclaren wrote:
> On Dec 30 2008, Bill Long wrote:
>>
>> I've thought about the various proposed solutions to the problem of 
>> protecting a buffer used for a split send/receive - wait pair of 
>> calls.  In particular, the need to prevent motion of code involving 
>> the buffer across the wait call. Most of them seem to have at least 
>> one defect.  Here is a possible solution (not entirely original) that 
>> I think works, and involves minimal and localized changes in the 
>> Fortran spec:
>>
>> Introduce a new subprogram prefix named VOLATILE.
>>
>> A VOLATILE subroutine:
>>
>> 1) must also be BIND(C)
>>
>> 2) may modify any variable accessible in the program unit that calls 
>> the subroutine
>>
>> The VOLATILE prefix is not required to match between an interface and 
>> the actual definition of the subprogram.
>>
>> Restriction (1) gets around the objection that the concept really 
>> makes no sense in the Fortran-Fortran case.  Restriction (2) will 
>> require that variables be reloaded from memory after a call to a 
>> volatile subroutine, and that code motion across the call is 
>> effectively blocked. 
>
> Sorry, but that dog won't hunt.
>
> Firstly, MPI non-blocking buffers have ASYNCHRONOUS semantics, and so 
> can be
> updated at any time between the isend/irecv and the wait.  In particular,
> many programs put wrappers around the MPI calls (often to enable RDMA
> transports as an option), and so the buffer variable may not be 
> visible in
> the procedure that calls the wait.

Agreed.  This is a good argument in favor of the proposal.  It's not 
trying to guess which variables might or might not be affected, but 
rather focuses on preventing motion of ANY code across a call to a 
volatile subroutine.  That's the ultimate goal, and this is one way to 
put that requirement into the standard.


>
> Secondly, there are big problems with all visible variables. Some 
> variables are syntactically read-only, but that is the easy bit. What 
> about DO-loop indices surrounding the wait, or arguments associated 
> with expressions? That specification makes such usages undefined.

Agreed.  It should be limited to definable visible variables.

>
> Thirdly, it is horribly unstructured and leads to catastrophic 
> inefficiency
> if extended to allow asynchronous update (as would be needed), because 
> all
> visible variables would be effectively VOLATILE.

On this you've entirely missed the point.  Making all variables volatile 
in the scope would, indeed, be a major performance problem.  By making 
the subroutine volatile instead, the pseudo-volatility of the variables 
is isolated to just the one CALL statement, and does not affect 
performance elsewhere. As stated before, there is some potential 
performance hit at the call site itself, but any register reloads after 
the call would likely be coming from cache so the actual hit might be 
small. 


Cheers,
Bill

>
>
>
>
> Regards,
> Nick Maclaren,
> University of Cambridge Computing Service,
> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
> Email:  nmm1 at cam.ac.uk
> Tel.:  +44 1223 334761    Fax:  +44 1223 334679
>
>

-- 
Bill Long                                   longb at cray.com
Fortran Technical Support    &              voice: 651-605-9024
Bioinformatics Software Development         fax:   651-605-9142
Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120