Re: Why "lock" functionality is introduced for all the objects?

On 28.06.2011 19:33, Stefan Ram wrote:


I have doubts about the viability of the alternatives suggested in that
article. I commented

I don't think the interface is a proper solution. Reason is that you
can pass in a lockless instance of class Foo which implements this
interface anywhere where Object is allowed. This means that you must
check at runtime whether the instance is lockable or not. That might
introduce significant overhead for applications which frequently
synchronize. A better way I can think of off the top of my head would
be a superclass of Object, but that would break in various other ways
(e.g. because suddenly Object.class.getSuperclass() would return a non
null value which breaks the existing contract). This leaves us with
data-only type. But this would dramatically change the type system,
namely you need two different types of references. This might not be a
big deal for the compiler but it may make GC much more complex because
now there is no longer a uniform object type on the heap. GC is complex
enough in modern JVMs so this could be a significant burden.

Kind regards

    robert

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/