Subject: Re: hpff-task: extension to the on-clause and alternative for task regions

From: Piyush Mehrotra <[email-masked]>
Date: Tue, 19 Sep 1995 09:24:29 -0400 (EDT)

---------------------------------------------------------------------------
[email-masked] is a mailing list for discussion of control-parallel
features in HPF.  Instructions for adding or deleting yourself from this
list appear at the bottom of this message.
---------------------------------------------------------------------------

> 
>   ON clauses with LOCAL would make it possible to write a class
>   of task parallel programs. The tradeoffs with using a task
>   region are:
> 
>   1. As you pointed out, there is no reasonable way to access
>      global/common variables from tasks. At the previous HPF
>      meetings, several people conveyed that the code in tasks should
>      be general and should allow access to common blocks. 
> 

There is no restriction on accessing global and/or common variables
with the LOCAL proposal, the only restriction is that they be mapped
onto the set of processors specified in the on clause.
Thus if a global variable or common block is mapped onto
a different subset of processors (or all the processors)
then the on-block cannot access the variable.

The problem with allowing access to any global variable is that
it involves other processors during the execution unless we make the
assumption that either a) there is support for one-sided communication
in hardware or software, or b) the compiler/runtime system determines
all globals accessed by an on-block (including all the way down the 
call chain) and then ensures that they are communciated to the processors
of the on-block before execution of the on-block.  Neither of these
approaches seems to be very palatable.

>   2. I am not sure how I/O constraints can be specified in this model
>      (short of something  ugly like specifying unit numbers as LOCAL
>      to an ON region). In the task region model (and in INDEPENDENT
>      loops) I/O constraints can be specified relatively since a
>      relevant code section is defined. Without a task region, the entire
>      program has to be considered.

One can certainly propose that replicated variables can be read in
any on-block to solve the above problem.  Note that in your pipeline
example (that I repeated) the variable done1 had to be mapped onto P1.

In your task region proposal, you have broken the specification 
into two parts, one a task region directive and another the 
on-block directive. The two combined together provide 
the effect that you want. In my proposal,  I was trying to 
bring the two together into the same directive thus hoping to
avoid the need for more syntax.

> jaspal

	- Piyush

---------------------------------------------------------------------------
To (un)subscribe to this list, send mail to [email-masked].
Leave the subject line blank, and in the body put the line
(un)subscribe <email-address>
---------------------------------------------------------------------------

---

From: [email-masked]
Date: Tue, 19 Sep 95 15:02:10 -0400

I will be happy if we the ON construct obviates the need for
begin...end task region, but I think the model you propose may
be too restrictive. Our earlier proposal was functionally equivalent
to this and my sense from the previous HPF meetings is:

a) Access to distributed global structures (common blocks) from
   tasks is important. This cannot be supported well without 1
   way communication.

b) Since 1 way communication is needed anyway to compile INDEPENDENT
   loops, there is no reason to constrain task parallelism for that
   reason.

>example (that I repeated) the variable done1 had to be mapped onto P1.

I am not sure if I understand this. The problem I was thinking of was 
how to disallow parallel tasks from performing I/O from the same unit 
in parallel.

Anyway, perhaps we can discuss further this tomorrow.

jaspal