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

[N.M. Maclaren]

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.

Regards,
Nick.