Very limited shared promotion

[Walter Bright]

On 6/17/2019 4: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?
> 

Using the resulting value of x:

   int x;
   void fun(scope ref shared(int) x) { ... }
   fun(x); // implicit promotion to shared in this case
   int y = x; // add this line

And now there's a problem. The compiler thinks x is thread local, so it doesn't 
add synchronization to the read of x. Not adding synchronization means that 
although fun() has terminated all the threads it spawned accessing x, it does 
not mean the memory caches of x are updated.

While you may have coded fun() to update the caches of x before returning, the 
compiler can't know that, and so the compiler cannot allow the implicit conversion.

In other words, adding `scope` does not guarantee SC-DRF (Sequential Consistency 
- Data Race Free).