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

[Sean Kelly]

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.