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