<div class="gmail_extra">On 15 November 2012 13:38, Jonathan M Davis <span dir="ltr"><<a href="mailto:jmdavisProg@gmx.com" target="_blank">jmdavisProg@gmx.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">On Thursday, November 15, 2012 11:22:30 Manu wrote:<br>
> Not to repeat my prev post... but in reply to Walter's take on it, it would<br>
> be interesting if 'shared' just added implicit lock()/unlock() methods to<br>
> do the mutex acquisition and then remove the cast requirement, but have the<br>
> language runtime assert that the object is locked whenever it is accessed<br>
> (this guarantees the safety in a more useful way, the casts are really<br>
> annying). I can't imagine a simpler and more immediately useful solution.<br>
><br>
> In fact, it's a reasonably small step to this being possible with<br>
> user-defined attributes. Although attributes have no current mechanism to<br>
> add a mutex, and lock/unlock methods to the object being attributed (like<br>
> is possible in Java/C#), but maybe it's not a huge leap.<br>
<br>
</div>1. It wouldn't stop you from needing to cast away shared at all, because<br>
without casting away shared, you wouldn't be able to pass it to anything,<br>
because the types would differ. Even if you were arguing that doing something<br>
like<br>
<br>
void foo(C c) {...}<br>
shared c = new C;<br>
foo(c); //no cast required, lock automatically taken<br>
<br>
it wouldn't work, because then foo could wile away a reference to c somewhere,<br>
and the type system would have no way of knowing that it was a shared variable<br>
that was being wiled away as opposed to a thread-local one, which means that<br>
it'll likely generate incorrect code. That can happen with the cast as well,<br>
but at least in that case, you're forced to be explicit about it, and it's<br>
automatically @system. If it's done for you, it'll be easy to miss and screw<br>
up.<br></blockquote><div><br></div><div>I don't really see the difference, other than, as you say, the cast is explicit.</div><div>Obviously the possibility for the situation you describe exists, it's equally possible with the cast, except this way, the usage pattern is made more convenient, the user has a convenient way to control the locks and most importantly, it would work with templates.</div>
<div>That said, this sounds like another perfect application of 'scope'. Perhaps only scope parameters can receive a locked, shared thing... that would mechanically protect you against escape.<br></div><div><br></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
2. It's often the case that you need to lock/unlock groups of stuff together<br>
such that locking specific variables is of often of limited use and would just<br>
introduce pointless extra locks when dealing with multiple variables. It would<br>
also increase the risk of deadlocks, because you wouldn't have much - if any -<br>
control over what order locks were acquired in when dealing with multiple<br>
shared variables.</blockquote><div><br></div><div>Your fear is precisely the state we're in now, except it puts all the work on the user to create and use the synchronisation objects, and also to assert that things are locked when they are accessed.</div>
<div>I'm just suggesting some reasonably simple change that would make the situation more usable and safer immediately, short of waiting for all these fantastic designs being discussed having time to simmer and manifest.</div>
<div><br></div><div>Perhaps a usage mechanism could be more like:</div><div>shared int x, y, z;</div><div>synchronised with(x, y, z)</div><div>{</div><div>  // do work with x, y, z, all locked together.</div><div>}</div><div>
<br></div></div></div>