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

[Jonathan M Davis]

On Wednesday, May 30, 2012 12:12:15 Andrei Alexandrescu wrote:
> On 5/30/12 12:03 PM, Steven Schveighoffer wrote:
> > On Wed, 30 May 2012 14:32:59 -0400, Andrei Alexandrescu
> > 
> > <SeeWebsiteForEmail at erdani.org> wrote:
> >> On 5/30/12 10:47 AM, Steven Schveighoffer wrote:
> >>> Yes, you can just use a private mutex. But doesn't that just lead to
> >>> recommending not using a feature of the language?
> >> 
> >> I don't think so. Synchronized classes are the unit of scoped locking
> >> in D. If you want to do all scoped locking internally, make the class
> >> private.
> > 
> > Maybe you didn't read thoroughly the first part of my post (the example
> > that shows a deadlock that is easily preventable if the mutex isn't
> > exposed).
> 
> The mutex is not exposed.

No, you can't directly access the mutex externally, but a synchronized block 
used on a synchronized object uses the same mutex that the object does.

So, if you have

synchronized class C
{
}

then this synchronized block

C c;
synchronized(c)
{
}

will use the exact same mutex that any functions on C itself use. So, it's 
possible for code outside of your class to lock that mutex using a 
synchronized statement. They do _not_ have direct access to the mutex to do 
whatever they want with it, but they _can_ lock via synchronized statements, 
which means that the synchronized class does _not_ have total control over 
what code locks its mutex.

All that's required to fix this particular problem is to make it illegal to use 
a synchronized block on a synchronized object - either that or give 
synchronized object's two mutexes (one to use internally for its functions and 
one to be locked externally using synchronized blocks). The doesn't 
necessarily solve all of the issues being discussed here, but it _does_ solve 
the issue of a synchronized class not being the only entity with the ability 
to lock its mutex.

- Jonathan M Davis