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
a...@lycus.org
http://lycus.org
