Re: Mutable Objects and Thread Boundaries
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.
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth