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

[Andrei Alexandrescu]

On 5/30/12 10:40 AM, Regan Heath wrote:
> On Wed, 30 May 2012 18:16:38 +0100, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> wrote:
>> On 5/30/12 9:43 AM, Regan Heath wrote:
>>> On Wed, 30 May 2012 17:00:43 +0100, Andrei Alexandrescu
>>> <SeeWebsiteForEmail at erdani.org> wrote:
>>>
>>>> On 5/30/12 5:32 AM, Regan Heath wrote:
>>>>> On Wed, 30 May 2012 10:21:00 +0100, deadalnix <deadalnix at gmail.com>
>>>>> wrote:
>>>>>> You don't want to synchronize on ANY object. You want to synchronize
>>>>>> on explicit mutexes.
>>>>>
>>>>> +1 .. this is the key point/issue.
>>>>
>>>> TDPL's design only allows for entire synchronized classes (not
>>>> separate synchronized and unsynchronized methods), which pair mutexes
>>>> with the data they protect. This is more restrictive than exposing
>>>> mutexes, but in a good way. We use such a library artifact in C++ at
>>>> Facebook all the time, to great success.
>>>
>>> Can you call pass them to a synchronized statement? i.e.
>>>
>>> TDPLStyleSynchClass a = new TDPLStyleSynchClass();
>>> synchronized(a) {
>>> }
>>
>> Yes. Well I recommend acquiring the text! :o)
>>
>>> ... because, if you can, then you're exposing the mutex.
>>
>> No.
>
> For the purposes of this thread, and the anti-pattern/problem we're
> discussing, you are.

No. I explained in my previous post that the synchronized statement does 
not expose locks. This is not a matter of opinion.

> It is the combination of synchronized
> classes/methods (implicit locking) and external synchronized statements
> (explicit locking) which result in the unexpected, accidental, and hard
> to see deadlocks we're talking about here.

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.

>>>> People shouldn't create designs that have synchronized classes
>>>> referring to one another naively. Designing with mutexes (explicit or
>>>> implicit) will always create the possibility of deadlock, so examples
>>>> how that could happen are easy to come across.
>>>
>>> True. But in my Example 1
>>
>> Your example 1 should not compile.
>
> o.. k.. I expected you would get my meaning with the simplified example.
> Here you are:

[snip]

> Runs and deadlocks immediately.

Sure. As I said, synchronized helps with scoping the locks and unlocks, 
but not with deadlocks. You can rewrite the example with two bare 
mutexes just as well.



Andrei