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

[Jonathan M Davis]

On Monday, June 04, 2012 10:51:08 mta`chrono wrote:
> 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.

You can always create deadlocks, but if there's something which gives you 
little benefit but significantly increases the risk of deadlocks (e.g. making it 
easy to lock on a synchronized class' internal mutex via a synchronized 
block), then it's valuable to make it illegal. Because while it won't prevent 
all deadlocking, it _does_ eliminate one case where it's overly easy to 
deadlock.

- Jonathan M Davis