Difference between __gshared and shared.

John Colvin via Digitalmars-d digitalmars-d at puremagic.com
Thu Jul 9 07:40:15 PDT 2015


On Thursday, 9 July 2015 at 14:03:18 UTC, Jonathan M Davis wrote:
> Well, the compiler is free to assume that a variable that is 
> not marked as shared is thread-local. So, it's free to make 
> optimizations based on that. So, for instance, it can know for 
> a fact that
>
> auto foo = getFoo();
> auto result1 = foo.constPureFunction(); // This function 
> _cannot_ mutate foo
> auto result2 = foo.constPureFunction(); // This function 
> _cannot_ mutate foo
> auto bar = foo;
>
> So, it knows that the value of bar is identical to the value of 
> foo and that result1 and result2 are guaranteed to be the same,

Pretty sure that's the same as in C++. Unless there was an 
acquire operation/barrier in there, the compiler is free to 
assume that two sequential reads to a memory location, without an 
intervening write (only considering the same thread), will return 
the same result. The optimisations that are forbidden in C++ are 
more subtle.

> Really, we can't tell what subtle behavioral problems you're 
> risking with __gshared, because that depends on what the 
> compiler is currently able to do with the assumption that a 
> variable is in TLS. You run into all of the problems that you 
> risk with sharing variables in threads in C++ only worse, 
> because the D compiler is free to assume that an object is 
> thread-local unless it's marked as shared and thus can make 
> optimizations based on that, whereas the C++ compiler can't. 
> And you've thrown away all of the compiler's help by using 
> __gshared. __gshared is intended specifically for use with 
> interacting with C code where we don't really have a choice, 
> and you have to be careful with it.

Basically, __gshared pretends to compatible with C(++) globals, 
but in actual fact it doesn't share the same memory model so who 
knows what might happen... It's not just 
dangerous-so-be-very-careful, it's fundamentally broken and we're 
currently just getting away with it by relying on C(++) 
optimisers.


More information about the Digitalmars-d mailing list