For the secure classes you're talking about, option 2 is easier on the
class authors, and there's a lot to be said for that.
However, what is the cost of this option in classes that do not have
synchronized methods? Examples: the Collections classes, Swing, and
most of my code. (In the thread-safe Java code I've been writing the
past three years, I rely heavily on external, coarse-grained locking.)
----- Original Message -----
From: "Bill Pugh" <pugh@cs.umd.edu>
To: <javamemorymodel@cs.umd.edu>
Sent: Friday, December 01, 2000 6:18 PM
Subject: Race-proof mutable objects and synchronized constructors
Say you want to design a class Foo that is designed to work correctly,
even if references to Foo objects are passed between threads via a data
race (perhaps maliciously so). Strings are one example of a class we
need to have be race-proof.
For immutable classes, we have a solution: use final fields. But what
about for mutable classes?
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:29 EDT