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.


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:


 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:


 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