(j3.2006) (SC22WG5.5423) WG5 straw ballot on N2040

[David Muxworthy]

The following message bounced because the mail server did not recognize the sender?s address.  It has been added to the white list.
David


Begin forwarded message:

Date: Fri, 16 Jan 2015 22:54:57 -0800
From: Robert Corbett <rpcorbett at att.net>
Reply-To: Robert Corbett <rpcorbett at att.net>
Subject: WG5 straw ballot on N2040
To: "sc22wg5 at open-std.org" <sc22wg5 at open-std.org>


My vote is 3) No, for the following reasons.

Robert Corbett

------------------------------

I am still concerned about the features described in Clause 5.9
I understand that allowing stalled images to resume execution
is a desired feature.  I am not convinced that the feature as
described in the DTS can be implemented without imposing a
severe performance penalty.  I understand that the ability to
resume stalled images is an optional feature.  I think that
even an optional feature should be required to be implementable.

I would change my vote if a description of how the feature could
be implemented is provided, assuming that the proposed
implementation is reasonable.  (Implementation via an interpreter,
for example, would not satisfy me.)  I would like the proposed
implementation to be based on hardware and systems software that
is commonly available.  A proposal for an implementation for
x86/x64 Linux would be fine.  The description of TS.  A separate
paper, not subject to approval would suffice.

One implementation proposal I shall not accept is that the
implementation should be the same as whatever the GCC
implementation of C++ does for exception handling.  I spoke
with a member of Oracle's C++ team, and he said that Oracle's
implementation of C++ exception handling could not do
everything I told him the DTS requires.

The DTS imposes some implicit requirements on processors.  For
example, some Fortran features require an implementation to
perform synchronization.  An implementation of a CRITICAL
construct, a SYNC ALL statement, a parallel reduction, or
input/output is likely to involve synchronization.  If an
image stalls on a data reference during the execution of a
CRITICAL construct within the scope of execution of a CHANGE
TEAM construct, I assume that the DTS assumes that a lock
held by the image as part of the synchronization done for
the CRITICAL construct must be released before execution of
of the stalled image resumes.

The DTS does not appear to impose a requirement that storage
allocated during execution of a stalled image be released before
execution of the stalled image resumes.  Is the possible memory
leak permitted?

Fortran processors often acquire system resources during execution.
For example, some operating systems allow a process to use at most
a fixed number of locks and events.  To avoid running out of the
system resources, the process must release resources it acquired
when it no longer needs them.  Is it intended that the DTS require
that a process release such resources as are no longer needed when
an associated stalled image resumes execution, or is it a quality
of implementation issue?

Please respond to this e-mail using the e-mail address
Robert.corbett at oracle.com

End forwarded message