[dmd-concurrency] tail-shared by default?

Andrei Alexandrescu andrei at erdani.com
Sat Jan 9 10:04:31 PST 2010


Exactly.

On a related vein, it's time to vote - should we require sharedRead() 
and sharedWrite() for shared values, or not? The semantics is a bit 
messy, so I'm leery about it. On the bright side, the code becomes 
crisply clear regarding the order of shared operations. This is quite a 
significant advantage.

Also, please let me know if:

(a) you haven't received the PDF of the chapter draft yesterday

(b) you have received it but the fonts look crappy on your system

There have been some toolchain issues starting with ps2pdf and ending 
with mailman.


Thanks,

Andrei

Sean Kelly wrote:
> 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
> _______________________________________________
> 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