On Thursday, November 15, 2012 11:22:30 Manu wrote:
> Not to repeat my prev post... but in reply to Walter's take on it, it would
> be interesting if 'shared' just added implicit lock()/unlock() methods to
> do the mutex acquisition and then remove the cast requirement, but have the
> language runtime assert that the object is locked whenever it is accessed
> (this guarantees the safety in a more useful way, the casts are really
> annying). I can't imagine a simpler and more immediately useful solution.
>
> In fact, it's a reasonably small step to this being possible with
> user-defined attributes. Although attributes have no current mechanism to
> add a mutex, and lock/unlock methods to the object being attributed (like
> is possible in Java/C#), but maybe it's not a huge leap.
1. It wouldn't stop you from needing to cast away shared at all, because
without casting away shared, you wouldn't be able to pass it to anything,
because the types would differ. Even if you were arguing that doing something
like
void foo(C c) {...}
shared c = new C;
foo(c); //no cast required, lock automatically taken
it wouldn't work, because then foo could wile away a reference to c somewhere,
and the type system would have no way of knowing that it was a shared variable
that was being wiled away as opposed to a thread-local one, which means that
it'll likely generate incorrect code. That can happen with the cast as well,
but at least in that case, you're forced to be explicit about it, and it's
automatically @system. If it's done for you, it'll be easy to miss and screw
up.
2. It's often the case that you need to lock/unlock groups of stuff together
such that locking specific variables is of often of limited use and would just
introduce pointless extra locks when dealing with multiple variables. It would
also increase the risk of deadlocks, because you wouldn't have much - if any -
control over what order locks were acquired in when dealing with multiple
shared variables.
- Jonathan M Davis
