[prev in list] [next in list] [prev in thread] [next in thread]
List: jakarta-commons-dev
Subject: RE: Fast collections thread safe?
From: Elli Albek <EAlbek () altoweb ! com>
Date: 2001-11-28 3:06:57
[Download RAW message or body]
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:VasanthK@InterWorld.com]
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:VasanthK@InterWorld.com]
Sent: Monday, November 26, 2001 3:07 PM
To: 'commons-dev@jakarta.apache.org'
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:EAlbek@altoweb.com]
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:sorensenjan@yahoo.com]
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 <sorensenjan@yahoo.com> wrote:
> Date: Wed, 26 Sep 2001 23:44:48 -0700 (PDT)
> From: Jan Sorensen <sorensenjan@yahoo.com>
> Subject: RE: Fast collections thread safe?
> To: Jakarta Commons Developers
> <commons-dev@jakarta.apache.org>
>
> 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 <EAlbek@altoweb.com> 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:sorensenjan@yahoo.com]
> > 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" <craigmcc@apache.org>
> > 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:
> > > commons-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> > > commons-dev-help@jakarta.apache.org
> > >
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Get email alerts & NEW webcam video instant
> > messaging with Yahoo! Messenger.
> > http://im.yahoo.com
> >
> >
>
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> > commons-dev-help@jakarta.apache.org
> >
> >
>
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> > commons-dev-help@jakarta.apache.org
> >
>
>
> __________________________________________________
> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
--
To unsubscribe, e-mail:
<mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail:
<mailto:commons-dev-help@jakarta.apache.org>
--
To unsubscribe, e-mail:
<mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail:
<mailto:commons-dev-help@jakarta.apache.org>
--
To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic