Re: Numpty "synchronized" question with ArrayList
Hi Eric,
"Eric Sosman" <esosman@ieee-dot-org.invalid> wrote in message
news:ia3shk$mf7$1@news.eternal-september.org...
On 10/25/2010 7:25 AM, Richard Maher wrote:
Hi,
WRT JavaDocs for the ArrayList class: -
Note that this implementation is not synchronized. If multiple threads
access an ArrayList instance concurrently, and at least one of the
threads
modifies the list structurally, it must be synchronized externally. (A
structural modification is any operation that adds or deletes one or more
elements, or explicitly resizes the backing array; merely setting the
value
of an element is not a structural modification.) This is typically
accomplished by synchronizing on some object that naturally encapsulates
the
list. If no such object exists, the list should be "wrapped" using the
Collections.synchronizedList method. This is best done at creation time,
to
prevent accidental unsynchronized access to the list:
List list = Collections.synchronizedList(new ArrayList(...));
and so on. . .
Can someone please explain why locking/synchronizing on the ArrayList
instance itself is not sufficent to serialize access?
No one can explain, because it *is* sufficient -- provided you
remember to do it every time,
Ok, no problem.
and provided any clients that get a
view of your list also remember to do it every time,
Are you using view in the regular english sense of the word here or are
there specific Java constructs that you had in mind?
In my case the ArrayList is used internally, privately, and never return-ed,
but even if the opposite was the case then as long as the consumer(s) also
lock the ArrayList via their reference variables then all is serialized yes?
and ... The
value of synchronizedList() et al. is that you get an object that
takes care of its synchronization internally and automatically, even
if you or your clients get careless.
Ok I can see the usefulness/transparency. Thanks.
Note that even with an internally-synchronized list, external
explicit synchronization is sometimes necessary. For example,
List<Thing> slist = Collections.synchronizedList(...);
while (!slist.isEmpty()) {
Number num = slist.remove(0);
...
}
is faulty, because although the isEmpty() and remove() operations are
synchronized individually, the pair as a whole is not synchronized:
The state of slist could change after isEmpty() finishes and before
remove() starts. A sneakier failure:
for (Number num : slist) {
...
}
is faulty, because although the iterator() method (implied by the
loop) is synchronized, nothing protects the list from being changed
while the iteration is in progress. These need to be rewritten as
synchronized (slist) {
while (!slist.isEmpty()) {
Number num = slist.remove(0);
...
}
}
and
synchronized (slist) {
for (Number num : slist) {
...
}
}
even though slist "synchronizes itself."
Ah thanks for the heads-up.
--
Eric Sosman
esosman@ieee-dot-org.invalid
And thanks for the very useful response.
Cheers Richard Maher