On 31.05.2012 19:05, Regan Heath wrote:
Yes, and it's all more intentional/flexible than what we have now, but.. :)
Does it address what I thought was the main "problem" case. That is, as
soon as you lock 2 objects, one via a synchronized() statement and the
other via a synchronized method you can get a non-obvious deadlock. e.g.
synchronized class A
{
void foo() {} // implicitly locks instance of A
}
class B
{
void __lock() {} // locks instance of B
void __unlock() {} // unlocks instance of B
}
shared A a;
shared B b;
void main()
{
a = new shared(A)();
b = new shared(B)();
..start thread which locks a then b..
synchronized(b) // locks b 'explicitly'
{
a.foo(); // locks a 'implicitly'
}
}
.. but, hang on, can a thread actually lock a and then b? If 'a' cannot
participate in a synchronized statement (which it can't under this
proposal) then no, there is no way to lock 'a' except by calling a
member. So, provided 'a' does not have a member which locks 'b' - were
deadlock safe!
So.. problem solved; by preventing external/public lock/unlock on a
synchronized class. (I think the proposal should enforce this
restriction; synchronized classes cannot define __lock/__unlock).
Surprisingly it is. And if A can't access B it's fool-proof.
As to __lock/__unlock defined for synchronized classes, yes I believe
compiler should catch it.
--
Dmitry Olshansky
