commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael A. Smith" <>
Subject Re: FastArrayList, FastHashMap, FastTreeMap not thread safe
Date Wed, 10 Apr 2002 03:41:58 GMT
On Tue, 9 Apr 2002, Jack, Paul wrote:
> List and Map objects can return views on their contents
> that can be modified.  For instance, elements can be 
> removed from an ArrayList via its iterator().  Elements
> can be removed from a map via its keySet() or its values()
> collection.  A TreeMap can also return a submap that can
> be modified.  Generally, changes on a view of a collection
> are reflected in the original and vice-versa.
> The problem is, with FastArrayList or FastHashMap, in "fast"
> mode, if somebody tries to modify a collection view (say, a
> keySet() of a FastHashMap) they will never enter the FastHashMap's
> monitor.  The state of the FastHashMap can become corrupted if
> more than one thread attempts to modify its keySet(); and threads
> attempting a fast get(Object) on a FastHashMap while another
> thread modifies its keySet() may get faulty data back.

Can you file this as a bug?  That way we can be sure to track it.

> I'd recommend using the "unmodifiable" methods of the 
> java.util.Collections class to make the collection views immutable.
> This would solve the problem, but technically violate the contract
> of java.util.Map and java.util.List (which specify that views on
> a map or list must support all operations the original map or list
> supported).  

Unfortunately, making it unmodifiable is a non-baskwards compatible
change.  There may be users out there that are relying on the returned
views being modifiable.  It shouldn't be too difficult to synchronize
properly in the returned views -- just requires some time to actually work
on it.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message