synchronized (this[.classinfo]) in druntime and phobos

Dmitry Olshansky dmitry.olsh at gmail.com
Thu May 31 09:10:04 PDT 2012


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


More information about the Digitalmars-d mailing list