[dmd-concurrency] tail-shared by default?

[Sean Kelly]

I think we should, though one issue needs to be discussed related to this.  If we allow the compiler to optimize away use of atomic() when it can determine that atomic behavior is unnecessary then the exact same code may compile with one compiler and not another (if the second doesn't optimize in exactly the same manner).  This is a big enough issue that I'm almost inclined to say that atomic() isn't necessary, though I would hate to do so.  Are there any other options?

On Jan 9, 2010, at 10:04 AM, Andrei Alexandrescu wrote:

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