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

[Sean Kelly]

On Jan 7, 2010, at 12:34 PM, Steve Schveighoffer wrote:

> ----- 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).

Won't we be able to do:

    struct A { int x; shared(SList) lst; }

I'd think it would be pretty common to want a local reference to shared data.  Then you wouldn't have to pay for the atomic read required if the reference itself is shared.

> 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!

Yeah, a fully shared field inside a non-shared class doesn't sound right.  The smoke test for me is that I think about whether it would work with per-thread GCs.  If one thread has a reference to "shared" data that actually lives in another thread's heap or stack, there's a dangling reference issue if the thread terminates (at least in theory--the heap data could easily be handed off to the shared GC instead, but let's pretend this is impossible).

> 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?

See my example of "shared (Something) p" above.  This is consistent with how const and such work anyway.

> 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.

Right.