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

[deadalnix]

Le 04/06/2012 10:56, Jonathan M Davis a écrit :
> 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

At least illegal by default. The programmer may enable it by 
him/herself, but not fall in the trap inadvertently.