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 ??
