Re: stale objects in collections

Timo Nentwig wrote:


     Right.


     "Immutable" is the combination of "mutable" (meaning "changeable"
or "capable of change") with a negating prefix. When we say that
something is "immutable" we mean that it is "not mutable," that is,
that it does not or cannot change.

     Adding elements to a collection changes the collection; removing
elements from a collection also changes the collection. Something
that changes is not "immutable," so if you are adding and removing
things the the /Concurrency in Practice/ statement does not apply.

     Perhaps you think the operation of adding an element to a
collection is in some sense "write-only," and that this makes it
safe to use without synchronization? (I'm imagining an argument
something like: "The trouble with a mutable object is that different
threads can see the object's internals while they are in an inconsistent
state. But since `write-only' operations don't report the state, it
doesn't matter.") Is that anything like what you're thinking?

     The argument is wrong. Trivially, the add() method for a Set
does in fact report some of the Set's state, namely, whether the
element was already present in the Set before the add(). More
deeply, the add() method must inspect and modify the Set's internals
to insert the new element. The details of just what those internals
look like depend on what kind of Set you're using, but they will
all involve reading the state (or parts of it), making some decisions
and computations, and storing new values in state variables. It may
seem "from the outside" that add() is write-only (if you decide to
ignore the returned value), but in fact it cannot be so. (Consider:
even `++x' is not write-only, because it must retrieve the previous
value in order to calculate the new one.)

     You need synchronization whenever a mutable object is (or can
be) manipulated by multiple threads "simultaneously."

     You can skip the synchronization if only one thread at a time
can access the mutable object. A very common special case of this
is when only one thread has a reference to the object; you need no
synchronization because no other thread can interfere. Another case
arises in your scenario: There's an initial phase during which many
threads pound on the collection, and a final phase when only one
thread works with it. You need synchronization in the first phase
(to keep all those threads from trampling on each other), but you
do not need it in the second (because there's only one thread).

     You do not need synchronization for immutable objects, even if
many threads access them "simultaneously."

--
Eric Sosman
esosman@acm-dot-org.invalid