Subject: hpff-task: Re: Proposal for task parallelism

From: [email-masked] (Chuck Koelbel)
Date: Thu, 14 Sep 1995 15:33:46 -0500

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

Sounds to me like you're addressing my concerns.  Maybe it would also help
to explicitly mention that a processor group always has write access to
data mapped to it.  Also, note that "normal data-parallel mode" on some
machines may mean GET/PUT access; copying data in this way in ALL may not
be sufficient for the synchronization that you need.

                                                Chuck

---------------------------------------------------------------------------
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: Thu, 14 Sep 95 17:05:41 -0400

> data mapped to it. 

Actually it is mentioned that processor groups have unrestricted access
to their variables, but only as a comment. Excerpt:

[There are no other access constraints: Code  executing on ALL processors
 has unrestricted  access to all variable locations. A code block directed
 to execute ON a subgroup P has unrestricted access to all variable locations
 mapped to P]

Perhaps it should be in the main text.

> Also, note that "normal data-parallel mode" on some

If GET/PUT access is used, the compiler has to include explicit
synchronization like barriers for normal data parallel processing.
The compiler has to use "subset barriers" to be able to exploit task
parallelism. One concern is that if a full barrier is used around
ALL sections, then the program may be oversynchronized, so subgroup
barriers should be used in ALL as needed. e.g. if a variable in
group1 is copied to a variable in group2, correct use of subgroup
barriers will allow group3 processors to continue if there is no
other code in ALL that needs them.

Anyway, I think this is about efficient  compilation in GET/PUT model 
and I don't think it changes the specification or the basic execution
model.

jaspal