Re: Mutable Objects and Thread Boundaries

From:

Lew <noone@lewscanon.com>

Newsgroups:

comp.lang.java.programmer

Date:

Wed, 21 Jul 2010 00:34:51 -0400

Message-ID:

<i25tdb$1ql$1@news.albasani.net>

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

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.

Almost. Both the initialization of 'list' and the 'add()' to it
/happen-before/ the call to 'doSomethingWithList()', so you could more
compactly write:

  public void foo( int number )
  {
    final List <Integer> list = new ArrayList <Integer> ();
    list.add( number );

    new Thread( new Runnable()
    {
      public void run()
      {
        doSomethingWithList( list );
      }
    }).start();
  }

on account of
<http://java.sun.com/docs/books/jls/third_edition/html/memory.html#17.4.5>
"A call to start() on a thread happens-before any actions in the started thread."

The local variable 'list' must be final to be accessible to the inner class.

Be very careful with auto(un)boxing.

--
Lew