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.
