Very limited shared promotion

[Walter Bright]

On 6/21/2019 1:17 AM, Manu wrote:
> I agree it's 'theoretically' valid; that's why I suggested it and the
> construct makes sense.
> How would you write code that escapes the scope reference to another
> thread? This must require some @trusted code to achieve sharing
> between threads; at that point, the @trusted function is responsible
> for re-instating the thread-locality guarantees (which are trivial to
> implement). If you don't do @trusted mischief, there's no way to
> migrate the value across threads, so your synchronisation issue
> shouldn't exist if no @trusted code exists.

I attempted to explain this before. The trouble does NOT come from the shared 
function escaping a reference. It comes from the lack of memory coherency 
between threads.

Scope says NOTHING about synchronizing access to shared memory. NOTHING. Just 
because there's no longer a reference to the shared memory location from another 
thread does not mean all the memory caches are synchronized. For that, 
synchronization is needed, and your load of thread local `x` does NOT include 
the necessary synchronization.

If `x` was types as shared, the compiler WOULD include the necessary 
synchronization when reading it. That's what atomic reads are for. It's the 
entire point of atomic reads.