On 08/15/2015 07:06 PM, rsw0x wrote:
On Saturday, 15 August 2015 at 09:30:48 UTC, Jonathan M Davis wrote:
On the whole, if you understand how a variable in C/C++/C#/Java works,
you understand how shared works. It's just that unlike C++, normal
variables in D are thread-local, and shared is protected against
interacting with them in a manner which violates that, and some
non-atomic operations are illegal to protect you from shooting
yourself in the foot.
So, the spec probably needs more information on shared in it, but
there really isn't much to put.
- Jonathan M Davis
I'm not looking to understand how it works, I want to know exactly what
the spec says which appears to be nothing.
Yup. One goal was sequential consistency of accesses on shared data, but
this can be quite costly. I think the last thing I heard about it was
that any questionable access using built-in operations will just be
disallowed on shared data, and that the ordering of accesses has to be
done manually by using suitable druntime functions.
TDPL's only mention of
casting away shared(13.14.4) is "if you are absolutely positive that the
[...] list is completely private [...] you can cast away shared and use
it without any regard to threads"
It says nothing on the legality of this, or if it's undefined behavior,
What this section is saying is that casting away shared and using such
an object is defined behaviour as long as you can guarantee manually
that there is no reference to that data accessible to a different thread.
so am I to assume that shared is at best a suggestion and not actually a
guarantee?
The main point of shared is that _absence_ of shared is a guarantee. Of
course D's type system is not actually powerful enough to verify that
guarantee in the common scenario when ownership of references is passed
between threads.
Feels like an addition C++ would get.
Well, no. It is not a backwards-compatible addition.
