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

[Dmitry Olshansky]

On 30.05.2012 3:04, Andrei Alexandrescu wrote:
> On 5/29/12 3:56 PM, Alex Rønne Petersen wrote:
>> A mutex can be stored privately.
>
> It can, but that doesn't mean it will.
>
>> Any object can be locked on, meaning no
>> lock is effectively protected or private or... anything.
>
> To paraphrase you, "An object can be stored privately".
>
>> It encourages
>> shared locks, which is seriously the worst deadlock inducing
>> anti-pattern to have ever manifested in multithreaded programming.
>
> I'll ignore the hyperbole and continued posturing. Please understand it
> does absolutely nothing in carrying your point. A technical question I
> have is - what are shared locks, and what are superior alternatives to
> them?
>

I'll intervene. Following famous nerd motto "talk is cheap, show me the 
code" I strongly suggest discussing concrete scenarios. All "prone to 
deadlock sentiment" is trivia as in buyer beware.

That being said:

class iMutexed
{//implicit intent, explicit details
	Mutex mutex;
}

vs

class iMutexed
{//implicit intent, implicit details

//implicit mutex
}

Makes little to no difference. EXCEPT that designer of the class has no 
control what so ever over hidden mutex! Thus I believe the best way to 
fix it is to (say) require obj be a subclass of Mutex in order to use 
synchronized(obj). i.e.

class iMutexed: Mutex
{//explicit intent, implicit details

}

-- 
Dmitry Olshansky