On 30-05-2012 00:50, Andrei Alexandrescu wrote:
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.
Locks are deadlock-prone by design, whether used with objects or with
classic procedural programs. In fact they are better confined to objects
because the association between the protected data and the
synchronization object is clear.
There is no doubt that synchronization of any kind is hard and
error-prone no matter how you do it. But do you really think that the
situation is made better by allowing locking on *anything*, meaning that
locks are effectively resources shared publicly?
Besides, what's wrong with core.sync.mutex?
Your very argument that anyone can lock on it. To that, I'll add that
core.sync.mutex is not properly associated with the resource it
protects, so coding with bare mutexes is in fact inferior to coding with
synchronized objects.
Andrei
I'm not sure I follow.
A mutex can be stored privately. Any object can be locked on, meaning no
lock is effectively protected or private or... anything. It encourages
shared locks, which is seriously the worst deadlock inducing
anti-pattern to have ever manifested in multithreaded programming.
--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org
