Very limited shared promotion

[Manu]

On Wed, Jun 19, 2019 at 12:15 AM Timon Gehr via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On 18.06.19 15:29, Steven Schveighoffer wrote:
> > On 6/17/19 7:46 PM, Manu wrote:
> >> Is this valid?
> >>
> >> int x;
> >> void fun(scope ref shared(int) x) { ... }
> >> fun(x); // implicit promotion to shared in this case
> >>
> >> This appears to promote a thread-local to shared. The problem with
> >> such promotion is that it's not valid that a thread-local AND a shared
> >> reference to the same thing can exist at the same time.
> >>
> >> With scope, we can guarantee that the reference doesn't escape the
> >> callee.
> >> Since the argument is local to the calling thread, and since the
> >> calling thread can not be running other code at the same time as the
> >> call is executing, there is no way for any code to execute with a
> >> thread-local assumption while the callee makes shared assumptions.
> >>
> >> I think this might be safe?
> >>
> >
> > Seems like it would be safe, but what is the use case for it? If you
> > have a scope shared, which can't actually get shared with anything else,
> > what does it buy you?
> >
> > -Steve
>
> He would write @system code that leaks the reference to other threads
> temporarily, but ensures those references disappear once the parallel
> part of the computation has finished. His use case is @safe parallel
> foreach without having to explicitly qualify the variables in the outer
> scope as `shared`:
>
> void sum(){ // note: just to illustrate the concept
>      int result=0;
>      foreach(i;iota(1000).parallel){
>          static assert(typeof(result)==shared(int));
>          result.atomic!"+="(i);
>      }
>      static assert(typeof(result)==int);
>      return result;
> }

👍

We must get here.