The only mention of them in the spec is:

shared Attribute
The shared attribute modifies the type from T to shared(T), the same way as const does.

Am I missing something obvious?

On Thursday, 13 August 2015 at 21:29:42 UTC, rsw0x wrote:
> The only mention of them in the spec is:
>
> shared Attribute
> The shared attribute modifies the type from T to shared(T), the same way as const does.
>
> Am I missing something obvious?

There is this http://dlang.org/migrate-to-shared.html

But you are right, the spec is seriously lacking in details.

Anrei's TDPL book spent a lot of words on shared (and this book had kind-of-a-spec reputation), but I don't know how much of it is relevant now.

On Friday, 14 August 2015 at 12:43:26 UTC, thedeemon wrote:
> Anrei's TDPL book spent a lot of words on shared (and this book had kind-of-a-spec reputation), but I don't know how much of it is relevant now.

I know for a fact that a lot of the things related to shared in TDPL aren't implemented or considered anymore.

Is it really not documented anywhere of what shared actually does currently?
This is ridiculous.

On Friday, 14 August 2015 at 18:52:42 UTC, rsw0x wrote:
> On Friday, 14 August 2015 at 12:43:26 UTC, thedeemon wrote:
>> Anrei's TDPL book spent a lot of words on shared (and this book had kind-of-a-spec reputation), but I don't know how much of it is relevant now.
>
> I know for a fact that a lot of the things related to shared in TDPL aren't implemented or considered anymore.
>
> Is it really not documented anywhere of what shared actually does currently?
> This is ridiculous.

There is actually very little in TDPL which has not been implemented. Off the top of my head, the only ones that I can think of are multiple alias thises, synchronized classes, and memory barriers for shared. Now, the alias this issues is really the only one that doesn't have to do with shared, so what it explains about shared definitely isn't the current situation, but on the whole, what TDPL talks about has been implemented, and very little of it has changed, though a few things have (e.g. it was written before we had "weak" purity). So, you can't necessarily take what TDPL says as law, but it's close.

But even with shared, what TDPL says is essentially correct aside from the fact that it doesn't have memory barriers, and we don't have synchronized classes to help work with shared objects.

Now, as for shared in the spec... I don't know what it says without digging through it, but the spec is notoriously sparse in the information that it has. The current implementation of shared is pretty straightforward though. shared objects are not treated as thread-local and won't implicitly convert to or from thread-local. There are no memory barriers or any special protections for integrity across threads for shared any more than a normal variable in C/C++ has such protections. It's just that shared variables are actually shared across threads and are protected against implicitly converting to or from thread-local. The only other protections that shared provides is that some non-atomic operations are declared illegal by the compiler, forcing you to either use functions in core.atomic or to protect the variable with a mutex and cast away shared to operate on it.

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

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. 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, so am I to assume that shared is at best a suggestion and not actually a guarantee? Feels like an addition C++ would get.

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.

On Friday, 14 August 2015 at 18:52:42 UTC, rsw0x wrote:
> Is it really not documented anywhere of what shared actually does currently?
> This is ridiculous.

Well, as specified, it modifies type and there's little beyond that :)
Maybe you want to see its design rationale? For some reason specifications don't provide rationale. Maybe they're supposed to be succinct or obviously understandable.

On Thursday, 13 August 2015 at 21:29:42 UTC, rsw0x wrote:
> The only mention of them in the spec is:
>
> shared Attribute
> The shared attribute modifies the type from T to shared(T), the same way as const does.
>
> Am I missing something obvious?

https://issues.dlang.org/show_bug.cgi?id=14932