Hi Hui --
I believe that what you're seeing here is due to Chapel's injection of shadow
'const's for variables of simple types (like integers) when they cross from
their declared scope to a parallel scope. Specifically, by default, each task
will get its own 'const' copy of the variable to prevent accidental race
conditions. There's a short-and-sweet description of them in the 1.11 release
notes (http://chapel.cray.com/releaseNotes/1.11/01-LanguageCompiler.pdf) though
you can also read about them in the language specification and online
documentation ("task intents" and "forall intents" are keywords to look for).
To check this theory, I tried a few things with the 1.14 compiler such as
overriding the default intent for the coforall loop:
coforall loc in Locales with (ref gVar) {
and changing the type of gVar to a type that is passed to tasks by reference by
default (like an atomic variable). With either of those changes, the output
reported '0' every time as you expected.
Having said that, I want to caution that we've found ourselves running into a
few cases lately which have caused us to debate (a) whether the compiler's
doing "the right thing" and/or (b) what "the right thing" for a given case
should be. So while this case seemed to be behaving properly to me, if you run
into other cases that are surprising even taking task/forall intents into
account, please feel encouraged to report or ask about them.
It's interesting that you ask about a "locale private" mechanism in Chapel
(i.e., "don't permit remote locales to access this variable"), which could also
help the compiler by saying "I know that all references to this variable will
be local, so don't introduce any overhead to potentially communicate it if
you're uncertain." This is an idea that comes up fairly regularly, yet which
we have not yet pursued ourselves. I don't think it would be very hard to
implement, and I haven't heard anyone express outright opposition to it, but I
don't think we haven't had a compelling enough proposal or use case for it to
take it on ourselves yet. If you have ideas of how it should appear
syntactically and behave semantically, that would be interesting (and could be
the basis for a good CHIP). Interestingly, while this question gets asked a
lot, I'm not personally aware of many people who've gotten bitten by
accidentally modifying something remote that they weren't supposed to -- so if
you have war stories like that, we'd be interested to hear them.
Best wishes,
-Brad
Language and Compiler Improvements -
Chapel<http://chapel.cray.com/releaseNotes/1.11/01-LanguageCompiler.pdf>
chapel.cray.com
C O M P U T E | S T O R E | A N A LY Z E Language and Compiler Improvements
Chapel Team, Cray Inc. Chapel version 1.11 April 2, 2015
________________________________
From: Hui Zhang <[email protected]>
Sent: Monday, October 10, 2016 10:29:12 PM
To: Chapel Sourceforge Developers List
Subject: [Chapel-developers] variable's locale inquiry in parallel block
Hello,
I'm confused about the result of inquiring the variable's locale info inside a
parallel block:
code:
proc main() {
var gVar = 100;
coforall loc in Locales {
on loc {
writeln("Pos2: from
loc.id<http://loc.id>"+loc.id<http://loc.id>+", gVar="+gVar+",
gVar.loc="+gVar.locale.id<http://gVar.locale.id>);
}
}
}
output:
Pos2: from loc.id0, gVar=100, gVar.loc=0
Pos2: from loc.id2, gVar=100, gVar.loc=2
Pos2: from loc.id1, gVar=100, gVar.loc=1
Same results by using forall/begin/cobegin.
Variable gVar is defined in locale 0, if I use serial "for" instead of
"coforall", then the gVar.locale.id<http://gVar.locale.id> will all print "0",
which makes sense. However, why locale.id<http://locale.id> of the same
variable gVar is changed to be where it's accessed (loc.id<http://loc.id>) in
the parallel cases (while using coforall/forall/begin/cobegin) ???
Besides, since Chapel has this global view of variables no matter where they
are defined, it seems like a little dangerous to use because any locale can
easily modify the value of a variable that's defined in another locale if
someone happens to misuse variable names...Is there a locale-specific (like
private to the particular locale) variable mechanism that can prevent such
mistake in Chapel ?
Thanks !
Thanks
--
Best regards
Hui Zhang
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
