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

[deadalnix]

Le 30/05/2012 08:23, Sean Kelly a écrit :
> On May 29, 2012, at 4:07 PM, Andrei Alexandrescu<SeeWebsiteForEmail at erdani.org>  wrote:
>
>> On 5/29/12 3:58 PM, Alex Rønne Petersen wrote:
>>> On 30-05-2012 00:45, Andrei Alexandrescu wrote:
>>>> On 5/29/12 2:57 PM, Alex Rønne Petersen wrote:
>>>>> On 29-05-2012 23:33, Andrei Alexandrescu wrote:
>>>>>> On 5/29/12 1:37 AM, deadalnix wrote:
>>>>>>> I would say that breaking things here, with the right deprecation
>>>>>>> process, is the way to go.
>>>>>>
>>>>>> So what should we use for mutex-based synchronization if we deprecate
>>>>>> synchronized classes?
>>>>>>
>>>>>> Andrei
>>>>>
>>>>> core.sync.mutex
>>>>
>>>> That's worse.
>>>>
>>>> Andrei
>>>>
>>>
>>> I don't agree.
>>
>> One simple thing to understand is that core.sync.mutex does everything synchronized objects do, in a much less structured way. So it's tenuous to build an argument that synchronized classes do something wrong but bare, unstructured mutexes do something good.
>>
>>> Also, it is faster than object monitors. This was proven
>>> by David Simcha recently where he sped up GC allocations by some 40%-ish
>>> factor just by changing to a final class derived from core.sync.mutex.
>>> And no, that's not a bug in the monitor implementation. It's a
>>> limitation of the design.
>>
>> We'd need to take a look at that. I recall at a point Bartosz was working on cheap locks using the mutex word as a spin lock in certain circumstances. Anyhow, it's something that would be interesting to look at.
>
> I bet this is because monitors are lazily initialized, so the cost of acquiring a lock is more than just locking the underlying mutex. The implementation for built-in monitors really isnt great. I've been meaning to do something about that.

And it use double check locking the wrong way, so can eventually explode 
sometime.