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

[deadalnix]

Le 29/05/2012 23:54, Andrei Alexandrescu a écrit :
> 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
>

In java, you basically have no concurency built-in. Everything is shared 
by default, you can lock on anything (which is deadlock and liquid lock 
prone), you have dumb primitive like wait and notify that are perfect to 
cause race conditions.

Don't get me wrong, I do a lot of java code, and it isn't that bad in 
general. But for concurrency, this isn't the model we want.

In a more general scope, the problem of java is to believe that 
everything is OOP, including concurrency, when they are, in fact, 
different topics.

D already have much better tools that the one java provide 
(std.concurency, std.parallelism, TLS by default, transitive type 
qualifiers, . . .) that most these thing taken from java don't make any 
sense now.

For instance, what is the point of being able to lock on any object when 
most of them are thread local ??