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

[Steven Schveighoffer]

On Thu, 31 May 2012 11:39:06 -0400, Sean Kelly <sean at invisibleduck.org>  
wrote:

> On May 31, 2012, at 2:48 AM, Andrei Alexandrescu  
> <SeeWebsiteForEmail at erdani.org> wrote:
>
>> On 5/31/12 2:36 AM, Regan Heath wrote:
>>> On Wed, 30 May 2012 19:29:39 +0100, Andrei Alexandrescu
>>> <SeeWebsiteForEmail at erdani.org> wrote:
>>>> You can have deadlocks but with synchronized you can't leak locks or
>>>> doubly-unlock them. With free mutexes you have all of the above.
>>>
>>> I'm not suggesting using free mutexes. I'm suggesting keeping the mutex
>>> private inside the object.
>>
>> Ergo, you are suggesting using free mutexes. Your second sentence  
>> destroys the first.
>
> To be fair:
>
> auto m = new Mutex;
> synchronized (m) {...}
>
> Free mutexes but still safe. Scope guards obviously work too. That said,  
> I think the point of contention here is that because synchronized can  
> take an arbitrary object, it's possible to lock on a class for stuff  
> completely unrelated to what the class does internally. It's certainly  
> bad form though, and I don't know a good way to prevent it without  
> crippling synchronized.

See my suggestion and Dmitry's in other parts of this thread.  The idea is  
that you still allow synchronized(x), but only if the author of x allows  
it.

If we use lowering, and make the lock and unlock methods of some entity,  
then you can also use attributes to limit scope of synchronized.

For example, if we make synchronized(x) equivalent to calling x.lock() and  
x.unlock() correctly, if lock() and unlock() are private, then you can  
only call synchronized(x) from inside the instance.

-Steve