Re: JavaMemoryModel: Idiom for safe, unsynchronized reads

From: Joshua Bloch (jbloch@eng.sun.com)
Date: Fri Jul 02 1999 - 14:04:57 EDT


Raymie,

   Thanks for posting this! I think it's important that we make it clear
what we mean by the "synchronize-free, initialize-then-publish idiom." I'll
take a crack at your questions:

> Do extra ordering guarantees apply only for writes inside constructors
> or whether they extend to all writes that occur prior to publishing?

   I think constructors are a red herring (albeit a tempting one). I believe
that any solution that works for this idiom:

    private static foo;
    public Foo {
        if (foo=null)
            foo = new Foo(...);
        return foo;
    }

will also work for this one:

    private static foo;
    public Foo {
        if (foo=null) {
            private Foo baz = new Foo(...);
            baz.mumble(...);
            foo = baz;
        }
        return foo;
    }

(I've show the "single-check repeated-creation-possible" forms rather than
the "double-check guaranteed-single-creation" forms for brevity. Hopefully
it's orthogonal to the issue at hand.)

I believe this because the creation of one object typical implies the
creation, then initialization of one or more private objects within the
object being created. For example, creation of a String implies creation,
then initialization of a private, internal array of characters.

>If the former, does that mean the "initialize-then-publish" idiom does not
>extend to arrays?

   I think that arrays are another red herring. They're not special.
They're just one of many mutable objects (albeit the only one built in to
the language). Anything that applies to arrays also applies to other
mutable objects (e.g., HashMap, or Hashtable for you old timers).

>If the later, what constitutes "publishing", and do the
>extra ordering guarantees apply only to "immutable" objects, or to objects
>whose values stop changing after they are published?

    N/A, given my answer to previous questions.

>If they only apply to immutable objects, can arrays be "immutable"
>(they aren't by Doug's definition)?

     I don't buy Doug's definition. If an object contains a private final
reference to a mutable object, then the containing object isn't
*necessarily* immutable (though it may be, as in the case of String). When
I came up with the mods to Ch. 17 "synchronize-free, initialize-then-publish
idiom", I though a fair amount about coming up with a formal definition of
immutability, and I believe it's decidedly non-trivial.

                  Josh

-------------------------------
This is the JavaMemoryModel mailing list, managed by Majordomo 1.94.4.

To send a message to the list, email JavaMemoryModel@cs.umd.edu
To send a request to the list, email majordomo@cs.umd.edu and put
your request in the body of the message (use the request "help" for help).
For more information, visit http://www.cs.umd.edu/~pugh/java/memoryModel



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