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.
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?
OOP and concurrency are 2 orthogonal topics, and should be handled as
such.
Well there would be active objects that contradict that. But really it
is very natural to encapsulate together some data along with the mutex
that must be acquired to manipulate it. There are known issues with
inheritance, but they are not introduced by the approach, only exposed
by it.
Andrei
--
Alex Rønne Petersen
[email protected]
http://lycus.org
