[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