[J3] Feedback on 23-246: Concurrent tasks

[Cornille, Brian]

[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.
  *   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 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.
  *   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.
  *   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.

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/>
[cid:image001.png at 01DA451F.333476F0]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20240112/c685b871/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 2113 bytes
Desc: image001.png
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20240112/c685b871/attachment.png>
-------------- next part --------------
To: J3                                                     J3/23-246
From: Jeff Hammond
Subject: Concurrent tasks
Date: 2023-October-25

1. Introduction
===============

Previously, we have motivated the addition of an asynchronous
task construct to allow programmers to express the independent,
potentially concurrent property of arbitrary sections of code,
as an extension of the BLOCK construct.

This paper describes a specific implementation of this concept.

2. Proposal
============

TASK :: [ID = identifier]
  import-stmt

END TASK

The task construct is a generalization of existing asynchronous
I/O, which allows arbitrary user-defined code, as opposed to
merely what can be expressed in READ or WRITE statements.

The task construct allows the user to create multiple, non-
sequentially executing segments within a single image.
Once started, task segments are unordered relative to other
segments until synchronized.  They are ordered after
non-task segments and task segments that have already
completed.

The TASK WAIT and TASK INQUIRE statements are used to query
the identifier of a task segment, in the same manner as
WAIT and INQUIRE are used on I/O operations, but where the
required argument is the ID and the only other argument is
the optional status (STAT) argument.

The TASK WAIT construct allows multiple IDs for convenience.
When multiple IDs are used, the status argument indicates
the overall status of all tasks.

Restrictions:
- All variables modified by a task construct must have the
  ASYNCHRONOUS attribute.
- Multiple updates to a variable within a given epoch is
  implementation defined.
- The IMPORT statement allows the program to indicate what
  variables will be accessed by a task construct, in the
  same manner as its use in the BLOCK construct.
- Procedures invoked by a task statement must be PURE or
  ASYNC_SAFE.  The ASYNC_SAFE procedure attribute means
  that a procedure does not modify any variables visible
  to the program other than its arguments, variables whose
  lifetime is limited to the execution of the procedure
  (i.e. not SAVE), or files.

Using IMPORT for TASK requires modifications to C8100.

The ASYNC_SAFE attribute may be applied to procedures
that modify variables not visible to the Fortran program
that can be safely accessed used mechanisms not defined
by Fortran.  For example, C-interoperable procedures
that use synchronization constructs defined in the C
language may allow access to the same data from multiple
tasks, as if Fortran tasks are executed in a manner
equivalent to C11 threads.

3. Discussion
==============

This is an initial sketch of the asynchronous task
syntax proposal, based upon discussion with the
HPC subgroup.

4. Example
===========

program main
  implicit none
  integer :: i
  integer :: sync(10)
  real :: x(1000000)
  do i=1,size(sync)
    task :: sync(i)
      import, only :: x
      x(1 + (i-1) * 100000 : i * 100000) = sin(i)
    end task
  end do
  do i=1,size(sync)
    task wait( sync )
  end do
end program main

5. References
==============

- https://j3-fortran.org/doc/year/22/22-169.pdf
- https://j3-fortran.org/doc/year/23/23-174.pdf

===END===