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

[deadalnix]

Le 30/05/2012 17:50, Andrei Alexandrescu a écrit :
> On 5/30/12 2:40 AM, deadalnix wrote:
>> Le 30/05/2012 00:50, Andrei Alexandrescu a écrit :
>>> On 5/29/12 2:59 PM, Alex Rønne Petersen wrote:
>>>> On 29-05-2012 23:31, Andrei Alexandrescu wrote:
>>>>> On 5/29/12 1:32 AM, deadalnix wrote:
>>>>>> I already did some comment about this.
>>>>>>
>>>>>> Making any object synchronization is a very bad design decision.
>>>>>> It is
>>>>>> deadlock prone, it is liquid lock prone, it cause an overhead on any
>>>>>> object, and even worse, it is useless most of the time as D promote
>>>>>> thread locality (which is very good).
>>>>>
>>>>> Actually I think such a characterization is superficial and biased to
>>>>> the extent it becomes wrong.
>>>>
>>>> Really ? I think he's spot on.
>>>
>>> I'd be glad to think the same. Good arguments might be helpful. So far
>>> I've seen exaggerated statements and posturing. Such are entertaining
>>> but are of limited effectiveness in furthering a point.
>>>
>>
>> I have provided link in other posts to document the point. Not to
>> mention that my personal experience back up this too.
>>
>> I don't like what you are doing here, because you don't provide anything
>> and simply discard what don't fit the current design. For instance, you
>> didn't even considered the liquid lock problem.
>
> It would help if I knew what a liquid lock is. The first page of Google
> search doesn't help.
>
> I'm only discarding content-less posturing a la "worst idea ever",
> "useless", "very bad design decision" etc. Such is just immature. It is
> encouraging you have started sending content (the msdn paper), thanks,
> and please keep it coming.
>
>
> Thanks,
>
> Andrei

Ok let's me explain what liquid lock is. It is a common error in 
languages that allow lock on any object.

The phenomena is fairly simple, but lead to really tedious debugging 
session. It happen when you use an object that is useful for some 
functionality of your program as a mutex. This is OK because the 
instance is always the same. Then, later on, when adding new 
functionality/refactoring/whatever, you introduce a possibility to 
change the instance you lock on.

In such situation, you seems to lock in an appropriate manner, but you 
fail to ensure correct locking when it occur at the exact moment the 
object referred is changed.

This is really tedious to track down, and quite easy to create when 
several developers are working on the same codebase for an extended 
period of time. To avoid this, you must ensure that any reference on 
object you mutate isn't used somewhere as a mutex.

It is considered good practice in Java to not lock on any object and use 
a specific object to lock on. The reference to that object will be 
final, so it is guaranteed to not change.

For instance, Intellij issue a warning about that : 
http://www.coderanch.com/t/233943/threads/java/Synchronization-non-final-field

At the end, locking on any object cause trouble.

Locking on any object has proven itself to be a very bad design decision 
in Java and C#. I don't think it is immature to say that. This is well 
known in java community, and I guess it is too in C# (I have way less 
experience with C# ).