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

[Andrei Alexandrescu]

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