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

[Sean Kelly]

I think the per-thread gc thing will still work but it would require  
some compile-time magic to look for shared references.  Seems feasible  
if "new" were in the library.

Sent from my iPhone

On Jan 7, 2010, at 3:15 PM, Sean Kelly <sean at invisibleduck.org> wrote:

> 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.
> _______________________________________________
> dmd-concurrency mailing list
> dmd-concurrency at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-concurrency