[dmd-concurrency] tail-shared by default?

Sean Kelly sean at invisibleduck.org
Sat Jan 9 10:00:18 PST 2010


I think this will all actually work out if the compiler detects when a  
shared value doesn't escape its local scope and thus doesn't need  
synchronization. If I have a private shared class member of a local  
class instance then the compiler should reliably be able to determine  
that the reference itself isn't visible yo another thread and therfore  
doesn't need to be atomic.  Calls to the shared class instance will  
still need to be restricted to shared and synchronized members, but  
the call won't need to be atomic(a).foo().

Really, the only time references may need to be atomic is if they are  
public members of a shared instance or if they are global.

Sent from my iPhone

On Jan 8, 2010, at 11:36 PM, Walter Bright <walter at digitalmars.com>  
wrote:

>
>
> Steve Schveighoffer wrote:
>> I think the idea is sound because you *must* pass a pointer to  
>> shared data into a function, you can't actually pass the real data,  
>> so the pointer itself that lives on the stack should *never* be  
>> shared, it's always thread local.  Sharing stack data would be more  
>> of a pending disaster in my opinion, since stack data is  
>> deallocated at will by returning from a function!
>>
>>
>
> Think about passing a local by reference to another function, i.e.  
> ref parameters.
>
> If I understood you correctly, you are not talking about adjusting  
> the type, but about having something not be shared because it's a  
> local. Having special case rules often sound good, but later turn  
> out to have unforeseen consequences (C++ is full of them). They are  
> best avoided as much as possible.
> _______________________________________________
> dmd-concurrency mailing list
> dmd-concurrency at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-concurrency


More information about the dmd-concurrency mailing list