At 6:32 PM +0100 6/13/01, np087@mdx.ac.uk wrote:
>On Mon, 11 Jun 2001, Bill Pugh wrote:
>
>> This is similar to what happens when a constructor makes an object
>> visible to other threads before the object is completely constructed.
>> I don't recommend it, but the spec has to specify the semantics of
>> doing so.
>
>What's going to happen with this?
>JLS 8.8.3 seems to suggest it is disallowed: "There is no practical need
>for a constructor to be synchronized, because it would lock the object
>under construction, which is normally not made available to other threads
>until all constructors for the object have completed their work."
>
>Are constructors going to be allowed to be synchronized in the future?
>This makes it a bit clunky... deciding whether or not an object will be
>shared *for the whole class*. I think I'd prefer guaranteeing the
>reference's unavailability until the contructor had finished. I know it
>breaks some JITCs but something's got to give.
I think clearly the recommended practice will be to not allow objects
to be visible to other threads until they are fully constructed.
However, we may need to allow for cases where that is not true.
There is a very good reason for allowing constructors to be
synchronized; for normal methods, labeling the method as synchronized
is syntactic sugar; you could get them same effect by using a
synchronized block within the method. However, for constructors, you
can't use a synchronized block to get acquire a lock before the call
to super. However, labeling a constructor as synchronized would allow
this functionality.
This kind of change could only be done as part of a change in
classfile version numbers, since it would break old verifiers.
Bill
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:32 EDT