>Bill,
>
>I would prefer to change the Java syntax to allow
>
> static A makeA(int i) {
> return synchronized new A(i);
> }
>
>This wouldn't prevent unsynchronized methods from seeing uninitialized
>fields of A (nor would your suggested idium), but it would allow a
>correct concurrent programming style that allows a reference to this
>to escape the constructor (as would your suggestion).
>
>The principle difference is what gets locked when an instance of A is
>created. With your suggestion, the class object for A is locked. For
>mine, the new A is created in the locked state (with the monitor held).
>
>I can't make a strong case for allowing synchronized news, but it feels
>cleaner to me.
What would be the exact semantics you propose? The easy semantics
would be to say that after a object is created but before the
constructor is called, you call monitorenter on the object. After the
object is initialized, you call monitorexit on the object.
You couldn't incorporate that into the language without changing the
JVM verifier. The problem is that if the constructor throws an
exception, you would (presumably) still want to release the lock. But
the verifier will reject any attempt to do anything with the object
if an exception was thrown while creating it. I'm not even sure if it
would accept calling monitorenter on an uninitialized object.
If the intended semantics are "this object should be created
atomically", I think there a lots of reasons why you can't make that
work without more changes to the JVM than people are going to be
happy with.
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:27 EDT