Le 30/05/2012 17:50, Andrei Alexandrescu a écrit :
On 5/30/12 2:40 AM, deadalnix wrote:
Le 30/05/2012 00:50, Andrei Alexandrescu a écrit :
On 5/29/12 2:59 PM, Alex Rønne Petersen wrote:
On 29-05-2012 23:31, Andrei Alexandrescu wrote:
On 5/29/12 1:32 AM, deadalnix wrote:
I already did some comment about this.
Making any object synchronization is a very bad design decision.
It is
deadlock prone, it is liquid lock prone, it cause an overhead on any
object, and even worse, it is useless most of the time as D promote
thread locality (which is very good).
Actually I think such a characterization is superficial and biased to
the extent it becomes wrong.
Really ? I think he's spot on.
I'd be glad to think the same. Good arguments might be helpful. So far
I've seen exaggerated statements and posturing. Such are entertaining
but are of limited effectiveness in furthering a point.
I have provided link in other posts to document the point. Not to
mention that my personal experience back up this too.
I don't like what you are doing here, because you don't provide anything
and simply discard what don't fit the current design. For instance, you
didn't even considered the liquid lock problem.
It would help if I knew what a liquid lock is. The first page of Google
search doesn't help.
I'm only discarding content-less posturing a la "worst idea ever",
"useless", "very bad design decision" etc. Such is just immature. It is
encouraging you have started sending content (the msdn paper), thanks,
and please keep it coming.
Thanks,
Andrei
Ok let's me explain what liquid lock is. It is a common error in
languages that allow lock on any object.
The phenomena is fairly simple, but lead to really tedious debugging
session. It happen when you use an object that is useful for some
functionality of your program as a mutex. This is OK because the
instance is always the same. Then, later on, when adding new
functionality/refactoring/whatever, you introduce a possibility to
change the instance you lock on.
In such situation, you seems to lock in an appropriate manner, but you
fail to ensure correct locking when it occur at the exact moment the
object referred is changed.
This is really tedious to track down, and quite easy to create when
several developers are working on the same codebase for an extended
period of time. To avoid this, you must ensure that any reference on
object you mutate isn't used somewhere as a mutex.
It is considered good practice in Java to not lock on any object and use
a specific object to lock on. The reference to that object will be
final, so it is guaranteed to not change.
For instance, Intellij issue a warning about that :
http://www.coderanch.com/t/233943/threads/java/Synchronization-non-final-field
At the end, locking on any object cause trouble.
Locking on any object has proven itself to be a very bad design decision
in Java and C#. I don't think it is immature to say that. This is well
known in java community, and I guess it is too in C# (I have way less
experience with C# ).
