On Friday, 2 January 2015 at 23:26:57 UTC, Jonathan M Davis via
Digitalmars-d-learn wrote:
On Friday, January 02, 2015 19:47:50 John Colvin via
Digitalmars-d-learn wrote:
On Friday, 2 January 2015 at 13:14:14 UTC, Jonathan M Davis via
Digitalmars-d-learn wrote:
> Objects in D default to being thread-local. __gshared and
> shared both make
> it so that they're not thread-local. __gshared does it
> without
> actually
> changing the type, making it easier to use but also dangerous
> to use,
> because it makes it easy to violate the compiler's
> guarantees,
> because it'll
> treat it like a thread-local variable with regards to
> optimizations and
> whatnot.
I'm pretty sure that's not true. __gshared corresponds to
C-style
globals, which are *not* assumed to be thread-local (see
below).
No, the type system will treat __gshared like a thread-local
variable. It
gets put in shared memory like a C global would be, but
__gshared isn't
actually part of the type, so the compiler has no way of
knowing that it's
anything other than a thread-local variable - which is
precisely why it's so
dangerous to use it instead of shared. For instance,
__gshared int* foo;
void main()
{
foo = new int;
int* bar = foo;
}
will compile just fine, whereas if you used shared, it wouldn't.
- Jonathan M Davis
I understand that. As far as optimisations and codegen go, that
is not the same as being able to assume that something is
thread-local, far from it.
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.
Are you telling me that D does not obey the C(++) memory model?
That would be a fatal hole in our C(++) interoperability.
AFAIK, the only data in D that the compiler is allowed to assume
to be thread-local is data that it can prove is thread-local. The
trivial case is TLS, which is thread-local by definition.
