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

[mta`chrono]

Am 31.05.2012 17:05, schrieb Regan Heath:
> .. 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).
> 
> R
> 

I think it doesn't matter whether you expose your mointor / locking /
unlocking to the public or not. You can always unhappily create
deadlocks that are hard to debug between tons of spaghetti code.

shared A a;
shared B b;

void thread1()
{
     synchronized(a)  // locks A
     {
         synchronized(b)  // ... then B
         {
             // ..... code ....
         }
     }
}

void thread2()
{
     synchronized(b) // locks B
     {
         synchronized(a) // ... then A
         {
             // ..... code ....
         }
     }
}