<div>I read through a few papers on hazard pointers, and I still only know enough gun safety to know that the gun is always loaded.  But I can&#39;t help but ask...</div>
<div> </div>
<div>What if this code:</div>
<div> </div>
<div>void methodName(ref shared int a)</div>
<div>{</div>
<div>    do_stuff();</div>
<div> </div>
<div>    int a1 = borrowShared(a);</div>
<div> </div>
<div>
<div>    auto x = computeX(a1);</div>
<div>    auto y = computeY(a1);</div>
<div>    auto z = computeZ(a1);</div>
<div>    int xyz = combine(x, y, z);</div>
<div> </div>
<div>    returnShared(a, xyz);</div>
<div> </div>
<div>    more_stuff();</div>}</div>
<div> </div>
<div>Was converted to this (borrowing Sean&#39;s example):</div>
<div> </div>
<div>void methodName( ref shared int a )<br>{</div>
<div>   do_stuff();</div>
<div><br>   int temp1;<br>   do {<br>       int a1 = temp1 = a;</div>
<div> </div>
<div>
<div>       auto x = computeX(a1);</div>
<div>       auto y = computeY(a1);</div>
<div>       auto z = computeZ(a1);</div>
<div>       a1 = combine(x, y, z);</div></div>
<div>       </div>
<div>   } while( !atomicStoreIf( a, a1, temp1 ) );  // atomicStoreIf is a CAS<br></div>
<div>   more_stuff();</div>
<div>}<br></div>
<div>It would only work for single variable modifications of course, and if computeX,Y,Z is slow, it is probably pointless or a live-lock.  The user would need to understand that this is really a loop, so maybe a different syntax is needed:</div>

<div> </div>
<div>
<div>void methodName(ref shared int a)</div>
<div>{</div>
<div>    do_stuff();</div>
<div> </div>
<div>    bool quit = false;</div>
<div>    </div>
<div>    forshare(a; a1; ! quit) {</div>
<div>
<div>        auto x = computeX(a1);</div>
<div>        auto y = computeY(a1);</div>
<div>        auto z = computeZ(a1);</div>
<div>
<div>        quit = /* iteration count test or something */;</div>        a1 = combine(x, y, z);</div>
<div>    }</div>
<div> </div>
<div>    more_stuff();</div>}</div></div>
<div> </div>
<div>I included the quit concept as an optional feature to remind users that this might live-lock; they could of course say &quot;if (...) break&quot; at any time as well.</div>
<div> </div>
<div>(I&#39;m sure there are some critics who will say that putting easy to reach lock-free algorithm primitives next to simple to use language features is like selling rubber snakes and real snakes from the same bin.)</div>

<div> </div>
<div>Kevin<br></div>
<div class="gmail_quote">On Tue, Jan 5, 2010 at 6:58 PM, Andrei Alexandrescu <span dir="ltr">&lt;<a href="mailto:andrei@erdani.com">andrei@erdani.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div class="im">Kevin Bealer wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"> And I guess getting lock free systems right is normally<br>considered an &quot;experts only&quot; kind of thing, except maybe the one-pointer versions like linked list.<br>
</blockquote><br></div>Even lock-free slists are heinously difficult to define correctly...<br><font color="#888888"><br>Andrei</font> 
<div>
<div></div>
<div class="h5"><br>_______________________________________________<br>dmd-concurrency mailing list<br><a href="mailto:dmd-concurrency@puremagic.com" target="_blank">dmd-concurrency@puremagic.com</a><br><a href="http://lists.puremagic.com/mailman/listinfo/dmd-concurrency" target="_blank">http://lists.puremagic.com/mailman/listinfo/dmd-concurrency</a><br>
</div></div></blockquote></div><br>