synchronized (this[.classinfo]) in druntime and phobos

Andrei Alexandrescu SeeWebsiteForEmail at
Tue May 29 15:50:09 PDT 2012

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.


More information about the Digitalmars-d mailing list