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

[Alex Rønne Petersen]

On 30-05-2012 01:07, Andrei Alexandrescu 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.

Okay, let's get something straight here: The Mutex class in 
core.sync.mutex is *not* final. It does *not* force you to use it in a 
compositional fashion. You can inherit it just as any other non-final 
class. And when you use synchronized (mtx), where mtx is an instance of 
Mutex or a derived class, it will even do the Right Thing (TM) and lock 
on the mutex.

Mutex is effectively the synchronized object type that you want. Why not 
just use it?

>
>> 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.
>
>
> Andrei

-- 
Alex Rønne Petersen
alex at lycus.org
http://lycus.org