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

[Alex Rønne Petersen]

On 30-05-2012 00:45, Andrei Alexandrescu wrote:
> On 5/29/12 2:56 PM, Alex Rønne Petersen wrote:
>> On 29-05-2012 23:38, Andrei Alexandrescu wrote:
>>> On 5/29/12 5:26 AM, Alex Rønne Petersen wrote:
>>>> Generalized object monitors is the worst idea in programming language
>>>> and virtual machine design, ever.
>>>
>>> I think that's an exaggeration. Care to elaborate a bit?
>>>
>>> Andrei
>>>
>>
>> 1) You waste an entire word of memory in *every single object you ever
>> create*. And for the majority of objects, this word will always be
>> zero/null. Not to mention that when you do allocate a monitor, you also
>> get the actual memory of that monitor in addition.
>
> I agree. It would be better if synchronizable objects would be part of a
> sub-hierarchy such that not everyone pays for the word.
>
>> 2) Anyone can lock on any object meaning it's near impossible to see
>> where a deadlock might come from.
>
> What would be the alternative? Deadlocks are a natural consequence of
> the fact that indeed any thread can wait on a resource.

But mutexes allow proper encapsulation by hiding the mutex resource. As 
I've proven in the very OP of this thread, both druntime and phobos 
suffer from the anti-pattern that is locking on a public resource when 
you shouldn't. The language encourages doing it with this synchronized 
business.

>
>> 3) Encapsulation is completely broken as a result of (2).
>
> Again, what would be the alternative?
>
>> 4) There's a whole bunch of runtime and GC plumbing (which is even
>> broken in druntime right now) to support object monitors. To fix this
>> entire mess, we'd need weak references.
>
> That's more like an argument the implementation is imperfect, not that
> the idea is the worst ever.

Of course. But it's enough reason for me to have banned synchronized 
from my source base entirely. This point is a practical matter more than 
it's a design matter.

>
>> 5) This whole object monitor model goes against our "thread-local by
>> default" model. Synchronization is evil and should be explicit with
>> core.sync.mutex.
>
> But doing things with core.sync.mutex is a definite step backwards as it
> is prey to all of the issues above. For example, "anyone can lock any
> mutex". How is that progress?

You encapsulate the mutex and thereby avoid the anti-pattern I pointed 
out in the OP, which has evidently found its way into both druntime and 
phobos.

>
>
> Andrei
>
>

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