(j3.2006) (SC22WG5.4945) [ukfortran] AW: Thoughts on Reinhold's thoughts

[Bader, Reinhold]

> -----Urspr?ngliche Nachricht-----
> Von: N.M. Maclaren [mailto:nmm1 at hermes.cam.ac.uk] Im Auftrag von N.M.
> Maclaren
> Gesendet: Samstag, 30. M?rz 2013 11:47
> An: Bader, Reinhold
> Cc: Van.Snyder at jpl.nasa.gov; fortran standards email list for J3; sc22wg5
> Betreff: Re: AW: (SC22WG5.4945) [ukfortran] AW: (j3.2006) Thoughts on
> Reinhold's thoughts
> 
> On Mar 30 2013, Bader, Reinhold wrote:
> >
> > I understand your concerns (and admit that I am also out of my depth
> > where the semantics of advanced memory models are concerned), but would
> > like to make the following comments:
> >
> > (1) The memory model papers you reference use a concept of computation
> > that does
> >      not include synchronization operations. The discussion for Fortran
> > therefore needs
> >      to focus on two different levels: The first one concerning
> > operations that permit
> >      memory updates in unordered segments (atomics, events) - that's
> >      where the memory model is needed - , and the second one that should
> > be allowed
> >      to argue on the basis of *existing* synchronization semantics
> > (teams!).
> 
> Yes and no.  They do have synchronisation operations, actually, but they
> are semi-implicit.  In C++, all accesses to atomic variables potentially
> imply a fence, and the default ones include a release/acquire fence.
> It's not a scalable model, and is almost unimplementable except on
> cache coherent shared memory.
> 
> Also, the other aspect that makes me twitch is collectives.  These
> provide a communication channel that does not involve any form of
> synchronisation.  In that, they are very like atomics, but are not
> restricted to atomic variables :-(
> 
> > (2) The concrete examples I'd like to see of course do not constitute
> > mathematical
> >      proof. But they would provide valuable heuristics simple on whether
> > or not to
> >      continue considering the second alternative.
> 
> The trouble is that taking that approach has caused absolute chaos in
> the past, because this area is SO fiendish.  People have been completely
> unable to produce examples that fail, programs have failed in real life,
> that has been tracked down to an inconsistency in the standard, and it
> has been then found to be unfixable :-(
> 
> Both POSIX threads and OpenMP have that, redoubled in spades, and it
> has been 'resolved' in C and C++ only by incompatible changes to the
> languages.  Even so, C++ has one serious inconsistency that I know of
> (which we blocked in Fortran), and C has dozens - even excluding the
> old ones of incompatibilities in the serial specification.  In older
> languages, Modula 3 made a complete mess of this for the same reason,
> and there were almost certainly many others.
> 
> If you can tell me a particular aspect that you are thinking of, I will
> see if I can create an example.  But, currently, the proposals are just
> too inchoate (= just begun, with connotations of imperfect, undeveloped
> and immature) to do much more.

Nice term.  I agree. 

With respect to examples: I'd like to see whether an inconsistency with respect to the
"regular" coarray memory model (i.e. excepting atomics and such - these would be dealt 
with via "containment") can be produced if the synchronization requirements on CHANGE TEAM
are relaxed:

* will all sequences of SYNC ALL, ALLOCATE and DEALLOCATE work properly?
* will (with the added restrictions in section (F) of my comment file) all allowed partial synchronization
   statements (SYNC IMAGES, EVENT POST/WAIT, LOCK/UNLOCK) work properly?

Note that such cases of data races and synchronization deadlocks that are already possible
in F2008 coarrays are excluded - that's the tradeoff implicitly accepted by the programming model.

By "containment" I basically mean requirement T2 of N1930 (which itself may leave some room for interpretation). 
My suggestions generally are in direction of narrowing the semantics, except for the CHANGE TEAM
sync relaxation; while the narrowing is generally based on different reasoning, your examples may well turn out to 
demonstrate that the narrowing is required in order to avoid problems with the sync relaxation.

Note that since your suggestion also involves relaxation of the CHANGE TEAM synchronization semantics, 
you're under obligation of providing proof of correctness as well ...

> 
> Regards,
> Nick.