Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 90373 invoked from network); 10 Apr 2002 09:01:14 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 10 Apr 2002 09:01:14 -0000 Received: (qmail 27854 invoked by uid 97); 10 Apr 2002 09:01:25 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 27814 invoked by uid 97); 10 Apr 2002 09:01:24 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 27803 invoked from network); 10 Apr 2002 09:01:23 -0000 Sender: Christoph.Reck@dlr.de Message-ID: <3CB3FF5D.D0591018@dlr.de> Date: Wed, 10 Apr 2002 11:01:17 +0200 From: Christoph Reck Organization: DFD-DLR X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en, de MIME-Version: 1.0 To: Jakarta Commons Developers List Subject: Re: FastArrayList, FastHashMap, FastTreeMap not thread safe References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Paul, the contract of the Fast* collections is to be usable within *one* thread or in a context where a sychronisation is done outside by an encapsualting owner class. That is the reason for allowing it to be fast. This was discussed in the thrads at the time where these collections found their way in. Fast* designers please correct me if I'm wrong (I'm just recollecting this from my memory - which is near to overflowing with some threads here...;). :) Christoph "Jack, Paul" wrote: > > Hi, > > I noticed that version 2.0 of the Commons Collections > has been released so I thought I'd browse through the > code. While doing so I noticed something about > FastArrayList, FastHashMap and FastTreeMap. > > 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. > > 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). > > Here's the list of methods that worry me: > > FastArrayList.iterator() > FastArrayList.subList(int, int) > > FastHashMap.keySet() > FastHashMap.entrySet() > FastHashMap.values() > > FastTreeMap.keySet() > FastTreeMap.entrySet() > FastTreeMap.values() > FastTreeMap.subMap(Object, Object) > FastTreeMap.headMap(Object) > FastTreeMap.tailMap(Object) > > Here's a sample fixed implementation of FastHashMap.keySet(): > > public Set keySet() { > if (fast) { > return Collections.unmodifiableSet(map.keySet()); > } else { > synchronized (map) { > return map.keySet(); > } > } > } -- :) Christoph Reck -- To unsubscribe, e-mail: For additional commands, e-mail: