[dmd-concurrency] is shared going to be a type modifier?

[Steve Schveighoffer]

----- Original Message ----

> From: Andrei Alexandrescu <andrei at erdani.com>
> Steve Schveighoffer wrote:
> > Despite that, I think I get it.  The address to a shared member could
> > be passed to other threads, even though the full object is not, is
> > that correct?
> 
> Of course, plus the more frequent case is:
> 
> class SList { ... }
> struct A { int x; shared SList lst; }

This to me is a more normal usage.  The data that is shared is really the list, not the pointer to the list (but the reference is also shared because of the deficiencies of the type syntax).

To be more specific, the following case is odd to me because you are sharing data in the same memory segment as unshared data:

struct B
{
   int x;
   shared int y;
}

And in fact, declaring a variable of type B in a function puts shared data on the stack!

Hm... this brings up an interesting point.  If you want to say that a reference to a shared class is a thread-local, how do you do that?  For instance, in your struct A, you are most likely not going to share the actual reference lst (i.e. &a.lst), just what lst points to.  However, the compiler is going to assume you are sharing lst because that's what you declared.  So every access to lst is going to require special memory barriers (and technically wasted cycles).  Is there going to be a way around this?  With const it was not as important because const is a compile-time concept, but now the syntax deficiency is creeping into runtime and hurting performance.  I.e. are we going to get an equivalent "Rebindable" type constructor?

In fact, any shared class reference on the stack erroneously will create memory barriers around the stack variable itself -- you shouldn't be sharing any stack data.

-Steve