[J3] Feedback on 23-246: Concurrent tasks

[Jeff Hammond]

On 12. Jan 2024, at 14.18, Cornille, Brian via J3 <j3 at mailman.j3-fortran.org> wrote:

External email: Use caution opening links or attachments


[AMD Official Use Only - General]

Hi Jeff and others,

Thought I would kick off some discussion on the Concurrent tasks proposal (attached for reference).

  *   Should there be restrictions on nesting TASK constructs? Should TASK be added to the restrictions on TASK as well as PURE and ASYNC_SAFE procedures? This may be a good idea for a first pass and lifting that restriction would be an exercise for a future revision.

Where is ASYNC_SAFE defined?

We have discussed requiring PURE but it precludes a number of use cases, including I/O.  I am thinking that we make the default behavior require PURE and only access data explicitly referenced with an IMPORT (or other) statement, but that we permit users to do something like “IMPORT ALL” that places the burden of correctness on them.


  *   Do arguments to PURE or ASYNC_SAFE procedures that are INTENT(OUT) or INTENT(INOUT) require the ASYNCHRONOUS attribute? Does that need clarified in the restrictions? My gut reaction is yes.

I think the meaning of PURE and ASYNCHRONOUS are somewhat opposed to one another.  If you have data that is accessed in an ASYNCHRONOUS manner, how is that doing to comply with PURE?  Maybe I am not understanding properly.  Can you provide an example?


  *   I think in the discussion in the HPC subgroup had the ID with an ISO_FORTRAN_ENV opaque derived type. I do not think INTEGER is sufficient for ID unless you have both NEWID and ID as options. I believe the consensus was allowing users to manage the IDs manually was not a great idea, but NEWID would match with NEWUNIT of IO and provide that flexibility. The other option of course is the opaque derived type which would be able to handle the “inout” nature of ID as shown in the initial sketch. I haven’t formed a strong opinion on this yet but would lean towards the opaque derived type.

Sure, an opaque type makes a lot more sense than an integer.


  *   Can any of LOCK_TYPE, EVENT_TYPE, or NOTIFY_TYPE along with the associated LOCK/UNLOCK, EVENT POST/WAIT, NOTIFY/WAIT statements be reused to interact with TASK? LOCKs would be useful for internal synchronization between TASKs for example. Would this be a separate proposal? This can also be asked of the ATOMIC_* intrinsic procedures. I’d assume these would be additional proposals unless they can’t be disentangled from TASK itself.

No, because TASK allows a no-op implementation that does not make strong progress and that would lead to deadlock with inter-task synchronization.

I am probably doing to change the name of this feature to "BLOCK CONCURRENT” to make an analogy to DO and DO CONCURRENT, that is clear that it is a hint to the compiler rather than a prescription.  Many important use cases and some of the prior art in HPC work this way (OpenACC, OpenMP 3.5 tasks), while prior art that requires strong progress has been demonstrated to require significant implementation effort, which may limit implementer adoption (OpenMP 4 tasks).


  *   Can TASK WAIT and TASK INQUIRE be used inside TASK constructs? Maybe this would be convenient for creating task DAGs but erring on the side of disallowing it unless there are good use cases not easily expressed in another way would seem prudent.

Waiting on child tasks is perfectly reasonable.  Waiting on any other tasks is a complex synchronization primitive that can deadlock.  I recall there’s some important analysis in the context of Cilk.

Jeff


Thanks and best,
Brian Cornille


BRIAN CORNILLE
MTS Software System Design Engr.  |  AMD
Platform Solns US
O +(1) 512-602-0093
----------------------------------------------------------------------------------------------------------------------------------
Facebook<https://www.facebook.com/AMD> |  Twitter<https://twitter.com/AMD> |  amd.com<http://www.amd.com/>
<image001.png>
<23-246.txt>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20240114/a4d2ddb9/attachment-0001.htm>