Hello, Brad
​Got it, thanks !
Besides, when running on multi-locales, will all the global C variables
defined in the chapel/runtime be shared/accessed by all nodes ?​
On Tue, Oct 11, 2016 at 1:52 AM, Brad Chamberlain <[email protected]> wrote:
> 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"+loc.id+", gVar="+gVar+",
> gVar.loc="+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 will all print "0", which makes
> sense. However, why locale.id of the same variable gVar is changed to be
> where it's accessed (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
>
--
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
