On 15 November 2012 12:14, Jacob Carlborg <span dir="ltr"><<a href="mailto:doob@me.com" target="_blank">doob@me.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 2012-11-15 10:22, Manu wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Not to repeat my prev post... but in reply to Walter's take on it, it<br>
would be interesting if 'shared' just added implicit lock()/unlock()<br>
methods to do the mutex acquisition and then remove the cast<br>
requirement, but have the language runtime assert that the object is<br>
locked whenever it is accessed (this guarantees the safety in a more<br>
useful way, the casts are really annying). I can't imagine a simpler and<br>
more immediately useful solution.<br>
</blockquote>
<br></div>
How about implementing a library function, something like this:<br>
<br>
shared int i;<br>
<br>
lock(i, (x) {<br>
    // operate on x<br>
});<br>
<br>
* "lock" will acquire a lock<br>
* Cast away shared for "i"<br>
* Call the delegate with the now plain "int"<br>
* Release the lock<br>
<br>
<a href="http://pastebin.com/tfQ12nJB" target="_blank">http://pastebin.com/tfQ12nJB</a></blockquote><div><br></div><div>Interesting concept. Nice idea, could certainly be useful, but it doesn't address the problem as directly as my suggestion.</div>
<div>There are still many problem situations, for instance, any time a template is involved. The template doesn't know to do that internally, but under my proposal, you lock it prior to the workload, and then the template works as expected. Templates won't just break and fail whenever shared is involved, because assignments would be legal. They'll just assert that the thing is locked at the time, which is the programmers responsibility to ensure.</div>
</div></div>