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

[deadalnix]

Le 30/05/2012 00:53, Andrei Alexandrescu a écrit :
> On 5/29/12 3:01 PM, Alex Rønne Petersen wrote:
>> On 29-05-2012 23:54, Andrei Alexandrescu wrote:
>>> On 5/29/12 2:49 PM, Alex Rønne Petersen wrote:
>>>> On 29-05-2012 23:32, Andrei Alexandrescu wrote:
>>>>> On 5/29/12 1:35 AM, deadalnix wrote:
>>>>>> Le 29/05/2012 01:38, Alex Rønne Petersen a écrit :
>>>>>>> I should probably add that Java learned it long ago, and yet we
>>>>>>> adopted
>>>>>>> it anyway... blergh.
>>>>>>>
>>>>>>
>>>>>> That is what I was about to say. No point of doing D if it is to
>>>>>> repeat
>>>>>> previously done errors.
>>>>>
>>>>> So what is the lesson Java learned, and how does it address
>>>>> multithreaded programming in wake of that lesson?
>>>>>
>>>>> Andrei
>>>>
>>>> It learned that allowing locking on arbitrary objects makes controlling
>>>> locking (and thus reducing the chance for deadlocks) impossible.
>>>
>>> And how does Java address multithreading in general, and those issues in
>>> particular, today?
>>>
>>> Andrei
>>>
>>
>> It doesn't, and neither does C#. Java still encourages using
>> synchronized, and C# still encourages using lock, but many prominent
>> figures in those programming language communities have written blog
>> posts on why these language constructs are evil and should be avoided.
>
> Some citations (beyond the known fallacies of Java 1.0) would be great.
> Thanks.
>
>> Besides, it seems to me that D can't quite make up its mind. We have TLS
>> by default, and we encourage message-passing (through a library
>> mechanism), and then we have the synchronized statement and attribute.
>> It just seems so incredibly inconsistent. synchronized encourages doing
>> the wrong thing (locks and synchronization).
>
> Each paradigm has its place. Lock-based programming is definitely here
> to stay, and when the paradigm is needed, doing it with synchronized
> objects is better than most alternatives.
>
>
> Andrei

No !

You don't want to synchronize on ANY object. You want to synchronize on 
explicit mutexes.

See that link for instance : 
http://msdn.microsoft.com/en-us/library/ms173179.aspx

It is from microsoft, you can't assume it is C# bashing. It says : 
"Generally, it is best to avoid locking on a public type, or on object 
instances beyond the control of your application. For example, 
lock(this) can be problematic if the instance can be accessed publicly, 
because code beyond your control may lock on the object as well. This 
could create deadlock situations where two or more threads wait for the 
release of the same object. Locking on a public data type, as opposed to 
an object, can cause problems for the same reason."

Given example also create dumb object to lock on them instead of using 
this/any object.

Time has proven it is the way to go.

I have tracked race condition in large java codebase, and I conclude the 
same thing as microsoft's guys.