On 12 November 2012 04:30, Walter Bright <span dir="ltr"><<a href="mailto:newshound2@digitalmars.com" target="_blank">newshound2@digitalmars.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 11/11/2012 10:46 AM, Alex Rønne Petersen wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It's starting to get outright embarrassing to talk to newcomers about D's<br>
concurrency support because the most fundamental part of it -- the shared type<br>
qualifier -- does not have well-defined semantics at all.<br>
</blockquote>
<br></div>
I think a couple things are clear:<br>
<br>
1. Slapping shared on a type is never going to make algorithms on that type work in a concurrent context, regardless of what is done with memory barriers. Memory barriers ensure sequential consistency, they do nothing for race conditions that are sequentially consistent. Remember, single core CPUs are all sequentially consistent, and still have major concurrency problems. This also means that having templates accept shared(T) as arguments and have them magically generate correct concurrent code is a pipe dream.<br>

<br>
2. The idea of shared adding memory barriers for access is not going to ever work. Adding barriers has to be done by someone who knows what they're doing for that particular use case, and the compiler inserting them is not going to substitute.<br>

<br>
<br>
However, and this is a big however, having shared as compiler-enforced self-documentation is immensely useful. It flags where and when data is being shared. So, your algorithm won't compile when you pass it a shared type? That is because it is NEVER GOING TO WORK with a shared type. At least you get a compile time indication of this, rather than random runtime corruption.<br>

<br>
To make a shared type work in an algorithm, you have to:<br>
<br>
1. ensure single threaded access by aquiring a mutex<br>
2. cast away shared<br>
3. operate on the data<br>
4. cast back to shared<br>
5. release the mutex<br>
<br>
Also, all op= need to be disabled for shared types.<br>
</blockquote></div><br></div><div class="gmail_extra">I agree completely the OP, shared is really very unhelpful right now. It just inconveniences you, and forces you to perform explicit casts (which may cast away other attributes like const).</div>
<div class="gmail_extra">I've thought before that what it might be useful+practical for shared to do, is offer convenient methods to implement precisely what you describe above.</div><div class="gmail_extra"><br></div>
<div class="gmail_extra">Imagine a system where tagging a variable 'shared' would cause it to gain some properties:</div><div class="gmail_extra">Gain a mutex, implicit var.lock()/release() methods to call on either side of access to your shared variable, and unlike the current situation where assignment is illegal, rather, assignment works as usual, but the shared tag implies a runtime check to verify the item is locked when performing assignment (perhaps that runtime check would be removed in -release for performance).</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">This would make implementing the logic you describe above convenient, and you wouldn't need to be declaring explicit mutexes around the place. It would also address the safety by asserting that it is locked whenever accessed.</div>