[J3] Thoughts on the semantics of generics

[William Clodius]

The problem is that the O(1) access of arrays makes DO CONCURRENT more useful for them than  for other structures. An exception might be unrolled lists, aka vectors, where the O(ln(N)) access to array segments, and O(1) access to elements within a segment, makes concurrency a more useful concept. Thinking further another exception might be hash tables where the underlying array can be processed in segments skipping the empty slots in each segment. A question is whether the result should have the same structure as the source, what I would expect for a hash table, or be flattened, which I would often find convenient for an unrolled list.

> On Aug 13, 2018, at 2:36 AM, Van Snyder via J3 <j3 at mailman.j3-fortran.org> wrote:
> 
> On Sun, 2018-08-12 at 16:25 -0600, William Clodius via J3 wrote:
>> The iterator proper usually provides a set sequential access, but it might be useful to allow a parallel access form, though
>> the history of the FORALL construct is discouraging.... Iterators and maps would often be simplified if Fortran included co-routines.
> 
> I don't think a CONCURRENT ITERATE construct using an iterator is problematic.  Its body would have the same rules as a DO CONCURRENT construct.  The loop control would initiate the iterator, then resume it repeatedly, launching a separate iteration of the body, until the iterator terminates instead of suspending.  If the processor actually parallelizes the iterations, each iteration would simply terminate instead of resuming the iterator.  This could be useful for a set container, but I don't see much use of it for iterating over intrinsically ordered containers, such as trees, stacks, queues, ....  That's not to say it should be prohibited, just that I don't see users using parallel iterators for intrinsically ordered containers.
> 
> Coroutines that are monitors could be resumed in different iterations of a DO CONCURRENT construct.  I don't see how one could initiate a coroutine in one iteration of a DO CONCURRENT construct and resume it in others.  I think it would have to be active first.  The statement to resume it would need a status, in case some iteration terminated it, or it terminated itself by running out of work to do.  An alternative to a monitor coroutine is to generalize critical sections to iterations of DO CONCURRENT constructs, and require testing and resuming coroutines to be done in critical sections.  Another alternative is simply a monitor subroutine that tests the coroutine's active status and if it's active resumes it.  This isn't as secure as a coroutine RESUME statement that returns a status, or a generalized critical section.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20180813/6fcfaec7/attachment.html>