What exactly shared means?

[John Colvin via Digitalmars-d-learn]

On Saturday, 3 January 2015 at 00:48:23 UTC, Peter Alexander 
wrote:
> On Friday, 2 January 2015 at 23:51:05 UTC, John Colvin wrote:
>> The rule (in C(++) at least) is that all data is assumed to be 
>> visible and mutable from multiple other threads unless proved 
>> otherwise. However, given that you do not write a race, the 
>> compiler will provide full sequential consistency. If you do 
>> write a race though, all bets are off.
>
> The memory is visible and mutable, but that's pretty much the 
> only guarantee you get. Without synchronization, there's no 
> guarantee a write made by thread A will ever be seen by thread 
> B, and vice versa.
>
> Analogously in D, if a thread modifies a __gshared variable, 
> there's no guarantees another thread will ever see that 
> modification. The variable isn't thread local, but it's almost 
> as if the compiler to treat it that way.
>
> These relaxed guarantees allow the compiler to keep variables 
> in registers, and re-order memory writes. These optimizations 
> are crucial to performance.

That is exactly how I understood the situation to be, yes.

2 questions I have to absolutely nail this down for good:

Does D assume that local variables are truly thread-local? I.e. 
can the compiler perform optimisations on local references that 
would break SC-DRF without first proving that it does not? 
Another way of putting it is: can a D compiler perform 
optimisations that are normally illegal in modern C(++) and Java?

If the answer to the above is yes, does the same apply to 
explicit use of __gshared variables?