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

Bader, Reinhold Reinhold.Bader
Sat Mar 30 05:48:46 EDT 2013


Hello Nick, 

> -----Urspr?ngliche Nachricht-----
> Von: owner-sc22wg5 at open-std.org [mailto:owner-sc22wg5 at open-std.org] Im
> Auftrag von N.M. Maclaren
> Gesendet: Samstag, 30. M?rz 2013 00:13
> An: Bader, Reinhold
> Cc: Van.Snyder at jpl.nasa.gov; fortran standards email list for J3; sc22wg5
> Betreff: (SC22WG5.4945) [ukfortran] AW: (j3.2006) Thoughts on Reinhold's
> thoughts
> 
> On Mar 29 2013, Bader, Reinhold wrote:
> >
> > Agreed. With respect to the big barrier in CHANGE TEAM let me note that
> > there are risks to any path we take:
> >
> > * if it is retained and no other way is found to *efficiently* exchange
> > data between teams, the teams feature will be regarded as a half-baked
> > solution by programmers
> >
> > * if it is removed and we fail to nail down the possible inconsistencies
> > that might result, implementors will start a head-hunt ...
> >
> > For this reason I'd like to see *concrete examples* that show how things
> > can go badly wrong if the synchronization requirements are relaxed.
> 
> I am afraid that is a serious mistake.  Virtually every design that has
> removed 'unnecessary' restrictions without a mathematical proof that it
> is safe to do so has introduced inconsistencies.  For example, UPC has
> defined behaviour that cannot practically be implemented - I was certain
> that it would deadlock when reading the specification, and I was right.
> That's in one of my old WG5 or J3 documents.  I.e. I think that the risks
> of the second path are vastly higher than those of the first one.
> 
> The problem about PGAS is that it is effectively a virtual shared memory
> model, and so has almost all of the problems of shared-memory models.
> Van's point is the key.  Unless we can prove (rigorously) that the model
> is correct, we should assume that it is incorrect, and will usually be
> right :-(

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!). 

(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. 

> 
> This is my point about desperately needing a defined memory model that
> we can prove is consistent.  POSIX and OpenMP don't have one, and are
> hopelessly broken as a result.  C++ does, and it's diabolically
> complicated.  I am getting somewhere with tracking down the relevant
> theory, and think that we can do something, but adding ANY complications
> to the basic segment model will probably break the approach I am looking
> at, and I don't know of another.
> 
> If anyone would like pointers to the relevant papers, please ask.  Be
> warned: the easiest of them are hard going, and some of them dive into
> HOL notation.  But they contain examples of truly horrible behaviour
> that really does get observed in practice - I have seen a certain amount
> of it, myself.
> 
> 
> Regards,
> Nick Maclaren.
> 




More information about the J3 mailing list