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

[Sean Kelly]

On Jan 7, 2010, at 1:57 PM, Steve Schveighoffer wrote:
> 

>> 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.
> 
> I think more than const, we need something like this for shared.

Yes.  If it can be done with a wrapper like Rebindable then great.  But not having any way around this would really stink.

>> 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).
> 
> Yeah, allowing this seems to imply that the global heap will have to be scanned for local heap collections:
> 
> class C
> {
>   shared(int)* ptr1;
>   int *ptr2;
> }
> 
> I assume that marking a single member shared makes C get allocated on the global heap.
> 
> If ptr1 points to a global-heap variable, and ptr2 points to a thread-local-heap variable, then you have to scan the global heap in order to collect the memory ptr2 is pointing to.

Until I learned that shared(x) doesn't actually work I didn't think this would be an issue.  Maybe it won't anyway?  With shared(int)* the type constructor behavior does kick in, right?  So you should have a local pointer to a shared int.  Classes are where this gets weird, and I guess you could have:

class C
{
    shared C ptr1;
}

shared C* x = &c.ptr1;

Pointers to handles are legal, right?

>>> 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.
> 
> No it is not.  If you have const(T) x, you can never rebind x, no matter what type is inside the parens.

Lame.  Oh well.  With const it isn't as big an issue.