www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Where are the semantics of shared defined?

reply "rsw0x" <anonymous anonymous.com> writes:
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?
Aug 13 2015
next sibling parent "Tofu Ninja" <emmons0 purdue.edu> writes:
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.
Aug 13 2015
prev sibling next sibling parent reply "thedeemon" <dlang thedeemon.com> writes:
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.
Aug 14 2015
parent reply "rsw0x" <anonymous anonymous.com> writes:
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.
Aug 14 2015
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Aug 15 2015
parent reply "rsw0x" <anonymous anonymous.com> writes:
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.
Aug 15 2015
parent Timon Gehr <timon.gehr gmx.ch> writes:
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.
Aug 15 2015
prev sibling parent "Kagamin" <spam here.lot> writes:
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.
Aug 18 2015
prev sibling parent "Jack Stouffer" <jack jackstouffer.com> writes:
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
Aug 18 2015