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

[Alex Rønne Petersen]

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
alex at lycus.org
http://lycus.org