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

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Tue May 29 15:45:07 PDT 2012


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.

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

> 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?


Andrei




More information about the Digitalmars-d mailing list