JavaMemoryModel: re: synchronized new

From: 914 (
Date: Tue Sep 12 2000 - 11:51:24 EDT


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.


------- Start of forwarded message -------
X-Sender: (Unverified)
Date: Tue, 12 Sep 2000 11:24:27 -0400
From: Bill Pugh <>

I've been struggling to formal something for final fields that would
handle lots of "reasonable" corner cases, and I'm not entirely happy
with the current results.

I think the situation for when no reference to an object is stored
into the heap while the object is being constructed is clear.

I think we need to expand that a little. For example, we should allow
an object to create an instance of an inner class in it's
constructor, so long as the only reference to that instance is from
the outer instance.

Here is a more complicated example (the kind of thing that is causing
me troubles)

class A {
   final int x;
   private static A lastA;
   A (int i) {
        lastA = this;
        x = i;
   static synchronized A makeA(int i) {
        return new A(i);
   static synchronized A getLastA() {
        return lastA;

In this example, the object being constructed is made reachable by
other threads during construction. However, synchronization is used
to ensure that no one actually loads a reference to the newly created
object until after construction is complete.

Is this an example of an acceptable or unacceptable programming
style. Forcing the semantics to accept this program will likely
result in a semantics that is harder to understand. However, I doubt
it would have any impact on the performance of programs.

- -------------------------------
JavaMemoryModel mailing list -
------- End of forwarded message -------
JavaMemoryModel mailing list -

This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:27 EDT