Where are the semantics of shared defined?
Timon Gehr via Digitalmars-d
digitalmars-d at puremagic.com
Sat Aug 15 14:14:40 PDT 2015
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.
More information about the Digitalmars-d
mailing list