Re: Mutable Objects and Thread Boundaries

From:

Alan Gutierrez <alan@blogometer.com>

Newsgroups:

comp.lang.java.programmer

Date:

Tue, 20 Jul 2010 22:10:04 -0500

Message-ID:

<i25oee$u0$1@news.eternal-september.org>

Joshua Cranmer wrote:

On 07/20/2010 10:06 PM, Alan Gutierrez wrote:

It was all the talk about the importance of immutability that made me
worry that field assignments that were unsynchronized or non-volatile
could be hidden from the receiving thread. This bit of documentation
that I missed, plus a first reading of JLS Ch 17, put that to rest.

Immutability is the easiest way to guarantee safe publication: final
fields guarantee that they can be used by any thread safely. Any other
type of object has to be safely published. Java Concurrency in Practice
lists four ways of doing it:
* Initializing an object reference from a static initializer
* Storing a reference to it into a volatile field or AtomicReference
* Storing a reference to it into a final field of a properly constructed
object
* Storing a reference to it into a field that is properly guarded by a
lock.

It also mentions that Java's thread-safe libraries all constitute safe
publication, because of their internal synchronization. To be clear, the
following are explicitly mentioned:
Hashtable, Collections.synchronizedMap, ConcurrentMap, Vector,
CopyOnWriteArrayList,CopyOnWriteArraySet, Collections.synchronizedList,
Collections.synchronizedSet, BlockingQueue, and ConcurrentLinkedQueue.

One key thing to note is that this safe publication only guarantees
visibility of changes made to an object before publication; anything
that happens afterwords must still be handled using regular
thread-safety techniques.

Very cool. Thank you.

I recall seeing something like this earlier today.

public void foo(int number) {
    final List<Integer> list = new ArrayList<Integer>();
    list.add(number);
    new Thread(new Runnable() {
        final List<Integer> happensAfter = list;
        public void run() {
            doSomethingWithList(happensAfter);
        }
    }).start();
}

And I understand now that by virtue of assigning to the final in the
Runnable, that makes the call to add happen before.

If that's correct, then I feel pretty confident that I get all this.

--
Alan Gutierrez - alan@blogometer.com - http://twitter.com/bigeasy