<div>So, if I understand correctly, the main thing the shared provides (relative to, say, an implicitely shared global in in gcc) is (relatively) simple memory barriers in the right places as well as compare and swap, which can be used to do lock-free style programming?</div>

<div> </div>
<div>One thing that strikes me as potentially tricky with the lock free style -- it seems like it isn&#39;t composable at all.  What I mean is that even if you get a really high quality and fast lock-free hash map running, if you need to take something (a struct, say) out of the hash map, do something with it, and then put it back in, you can write shared lock-free logic for the struct, and for the hash map, but you can&#39;t easily make the entire operation of take-out, update, put-back lock free in any easy way, right?</div>

<div> </div>
<div>On a theoretical level, these are cool structures but it seems like we will still have the problem that Java 1.0 had, which is that it had thread save Vector primitives but there was no way to enforce consistency between them.  Consistency only refers to one of the two lists at a time.</div>

<div> </div>
<div>Likewise, if you have a struct with one integer you can do CAS.  If you have two integers, you can figure out a 2-word CAS, but then if you have three you are sunk again.  If you come up with a trick for three, you lose with four.</div>

<div> </div>
<div>Since D has such great built in containers, doing things like associative arrays as lock-free seems great.  But I&#39;m thinking the majority of the time for ordinary users, this feature would be used either for simple insert, singly linked list, or fall back to a spin lock to surround all your operations (in which case you lose the guarantee that one thread can pause without hanging the app.)</div>

<div> </div>
<div>Kevin</div>
<div> </div>