[mpich-devel] datatype accessors with uncommited datatypes

[William Gropp]

We all agree that the language can be tightened up.

The approach taken was to specify what was required (commit for communication) and then point out that one important case where commit is not required is the case of datatype construction.

It is also extraordinarily dangerous to claim to cover all cases in the text - this is almost always doomed to failure.  Best is to do what you can and then rely on a consistent reading of the text.  Perhaps a better fix is to say that a commit is *only* required for datatypes used in communication.  Emphasize that in other cases, such as constructing a datatype, a commit is not required.  That is certainly the sense that was intended.

Bill

William Gropp
Director, Parallel Computing Institute
Deputy Director for Research
Institute for Advanced Computing Applications and Technologies
Paul and Cynthia Saylor Professor of Computer Science
University of Illinois Urbana-Champaign



On Dec 27, 2012, at 2:35 PM, Jeff Hammond wrote:

>> On 12/27/2012 02:05 PM US Central Time, William Gropp wrote:
>>> The standard is already clear - commit is only required when the
>>> datatype is used for communication.  It is unnecessary for the
>>> standard to list all cases where commit is not required - it is
>>> enough to list where commit *is* required, which it does.
> 
> This is argument of the form "unless something is explicitly
> prohibited, it is permitted," which is extraordinarily dangerous and
> inconsistent with a robust standards document.
> 
>> The way the text is currently written, it says "it is required for case
>> X and not required for case Y" instead of saying "not required for all
>> other cases".  If the intended behavior is to not throw an error for
>> non-communication routines, then the one example (of datatype
>> constructors) should be removed from the standard, or just rewritten as
>> "other operations such as datatype constructors".
> 
> Exactly.  The sentence "As an argument in datatype constructors,
> uncommitted and also committed datatypes
> can be used," should be removed completely or otherwise modified such
> that there is no potential for it to be misinterpreted as an exclusive
> list of permitted usage.
> 
> Jeff
> 
> -- 
> Jeff Hammond
> Argonne Leadership Computing Facility
> University of Chicago Computation Institute
> jhammond at alcf.anl.gov / (630) 252-5381
> http://www.linkedin.com/in/jeffhammond
> https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond