I did not use the fast collections in commons. I did, however write something very similar a long time ago. I experienced VM crashes in multi CPU machine that I suspect were caused by that code. As with any multi threaded code, the bugs are almost impossible to reproduce. The code was modified, I did not experience VM crashes after that.
Reading these articles, I am wondering if it is possible to implement fast collections at all in java. I assume that you can use fast collections as long as you are not modifying them at runtime, meaning you load all the collection values at initialization time, and after that you do not modify it. Also notice that if you load the entire collection when you initialize the system, the penalty of synchronization an operation like HashMap.get() is negligible. It is so quick, that even a real multithreaded machine will not feel any difference. I am wondering if there is any benchmark that shows what is the difference between using a synchronized MashMap or a FastHashMap for a real world use case, say storing struts Actions in a fast HashMap. E -----Original Message----- From: Kumar, Vasanth [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 27, 2001 8:43 AM To: 'Jakarta Commons Developers List' Subject: RE: Fast collections thread safe? Elli, Sorry, I haven't seen your whole thread, but as you might have seen from my previous post (below), there definitely seem to be thread-safety issues with the Fast collections. Only I think that the issue is related to the fact that in fast mode, when one thread is accessing the list without synchronizing another thread can be modifying the list. Are you using the Fast collections in your project in production? -----Original Message----- From: Kumar, Vasanth [mailto:[EMAIL PROTECTED]] Sent: Monday, November 26, 2001 3:07 PM To: '[EMAIL PROTECTED]' Subject: Question about FastArrayList To the designer(s)/author(s) of collections class FastArrayList: I was looking through the collections project and in particular I am interested in FastArrayList. However, I am concerned about possible isses with it. 1. When fast is true, assume that Thread 1 is inside get(int index) method on the line: return (list.get(index)); Meanwhile, Thread 2 sneaks in and calls setFast(false) changing fast to be false AND calls list.remove(int index). The list.remove() locks the list, but Thread 1 is actually accessing the list object at the same time without locking it. Suggestion: Changing the fast flag on a FastArrayList from false to true should be ok, but changing it from true to false (i.e. from fast to slow) should be prevented. This is because when switching fast mode to slow mode, already executing methods in fast mode need to complete the calls before the mode can be changed to slow. And the way to ensure this would be be to do more synchronization (including in the get() method) - which would defeat the purpose of the FastArrayList class (to allow for unsynchronized access). 2. The code in add(int index, Object element) could be a problem. When fast is true, threads can access the list ArrayList (using get()) without locking. Simultaneously, another thread can be adding items to the list. Synchronizing in just the add() method is not sufficient. Furthermore, it may seem that since a temp variable is assigned the clone of list in the add method, the new list will always be initialized properly, but based on what I have read, this may not be the case. Please refer to the Double-Check locking articles on Javaworld's site. In particular, refer to: http://www.javaworld.com/javaworld/jw-05-2001/jw-0525-double.html Suggestion: If you want to allow for unsynchronized access in the get() methods you should not allow any changes in fast mode (i.e. prevent add, remove, etc. in fast mode). Please let me know of your thoughts. Thanks Vasanth -----Original Message----- From: Elli Albek [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 27, 2001 12:05 AM To: Jakarta Commons Developers Subject: RE: Fast collections thread safe? One more iteration. Check out the link, I think we have exactly the same problem with fast collections. The new clone of the collection might be flushed to shared memory after its reference is. So other threads will see the object reference to the new collection, but the memory space for that object will be corrupt. So even though the pointer to the object is there, trying to use the object can have unexpected results. As weird as it sounds, I have seen these thing happen on multi CPU machines (that was a long time ago, JDK 1.1.7, but I am under the impression that the problem still exists). the article: http://www.javaworld.com/javaworld/jw-05-2001/jw-0525-double.html E -----Original Message----- From: Jan Sorensen [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 27, 2001 5:09 AM To: Jakarta Commons Developers Subject: RE: Fast collections thread safe? I realized that you can actually call the clone method through reflection, something like: Class c = object.getClass(); Method m = c.getDeclaredMethod("clone", null); // Should search of the super chain copy = m.invoke(obj, null); The getDeclaredMethod will get the clone method, and if the method is public invoke will successful execute it. In case object does not have a public clone, an exception will be thrown. For use in the fast collections, I think all the relevant collection implementation class provide a public clone, so I think it would work. -- Jan Sorensen --- Jan Sorensen <[EMAIL PROTECTED]> wrote: > Date: Wed, 26 Sep 2001 23:44:48 -0700 (PDT) > From: Jan Sorensen <[EMAIL PROTECTED]> > Subject: RE: Fast collections thread safe? > To: Jakarta Commons Developers > <[EMAIL PROTECTED]> > > I agree 100% with you, it doesn't make sense when > the > interfaces doesn't provide a clone. Didn't think > about > that. > > -- > Jan Sorensen > > --- Elli Albek <[EMAIL PROTECTED]> wrote: > > The problem with that is that you will need to > clone > > the wrapped > > collections, and the java.util package interfaces > to > > not support cloning. > > The implementing classes do support cloning. > > If we assume that the wrappers work directly on > the > > class and not the > > interface, then providing a wrapper API or an > actual > > class implementation > > API (as it is today) does not make any difference. > > > > Example: > > We cannot do something like > > Map FastCollections.fastMap(Map m) > > because Map does not support cloning. > > > > We will have to do something like: > > HashMap FastCollections.fastMap(HashMap m) > > > > and this is not much different than doing > > > > new FastHashMap(); > > > > My 2 cents > > > > E > > > > > > -----Original Message----- > > From: Jan Sorensen [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, September 26, 2001 12:00 AM > > To: Jakarta Commons Developers > > Subject: RE: Fast collections thread safe? > > > > > > Wouldn't it make sense to implemnt the fast > > collections as a kind of wrapper classes, similar > to > > Collections.synchronizedXxxxx. We could then > > implemnt > > FastMap, FastList, FastSet, FastCollection etc, > and > > get a "fast" version of all the collection > > interfaces. > > > > -- > > Jan Sorensen > > aragost > > > > > > --- "Craig R. McClanahan" <[EMAIL PROTECTED]> > > wrote: > > > > > > > > > On Tue, 25 Sep 2001, Elli Albek wrote: > > > > > > > [snip] > > > > By the way, the FastArrayList is subclassing > > > ArrayList but not using > > > > anything of it. > > > > I tried: > > > > public class FastArrayList extends > > > java.util.AbstractList { > > > > > > > > and: > > > > public class FastArrayList implements > > > java.util.List{ > > > > > > > > And they both compile. > > > > > > > > > > The reasoning for this subclassing was as > follows: > > > > > Even though the > > > Collections APIs tell people they should pass > List > > > as a method parameter > > > (instead of ArrayList), some people persist in > > > passing ArrayList instead. > > > If they did that, FastArrayList would not be a > > > plug-compatible > > > replacement. > > > > > > The argument is a little weak, and I'd be OK for > > > changing it -- if we > > > hadn't released it as is in Collections 1.0. > > > Unfortunately, changing it > > > now would be backwards incompatible for anyone > who > > > relied on the above > > > reasoning. > > > > > > > E > > > > > > > > > > Craig > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: > > > [EMAIL PROTECTED] > > > For additional commands, e-mail: > > > [EMAIL PROTECTED] > > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Get email alerts & NEW webcam video instant > > messaging with Yahoo! Messenger. > > http://im.yahoo.com > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > __________________________________________________ > Do You Yahoo!? > Listen to your Yahoo! Mail messages from any phone. > http://phone.yahoo.com > __________________________________________________ Do You Yahoo!? Listen to your Yahoo! Mail messages from any phone. http://phone.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>