commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Juozas Baliuka" <bali...@centras.lt>
Subject Re: [Collections] StaticBucketMap not thread safe
Date Wed, 26 Jun 2002 16:43:57 GMT
Hi,
doe's somebody tried to test StaticBucketMap for performance without
synchronization ?
I think we need to implement not thread safe, but "fast" map first and try
to synchronize it
after it will be "fast" ( as fast as java.util.HashMap is). I tired to
implement "fast" set,
but I see performace more depends on "loadFctor" and "initialCapacity" not
on implementation or algorythm and  hash functions are "good" and "bad" at
the
same time (all depend on input).



> > From: Berin Loritsch [mailto:bloritsch@apache.org]
> >
> > > From: Jack, Paul [mailto:pjack@sfaf.org]
> > >
> > > Ugh.  StaticBucketMap has double-checked-locking-esque problems.
> > >
> > > Since access to the node array (m_buckets) isn't
> > > synchronized, different processors can disagree as to whether
> > > an element in that array is null or not.
> > >
> > > Worse, the reference to a Node placed in that array can be
> > > written before the Node is fully constructed, because
> > > compilers/ pipelines can feel free to reorder those
> > > instructions.  Almost every operation on a StaticBucketMap
> > > can therefore fail in unexpected ways.
> > >
> > > Only way to fix it is to synchronize every access to
> > > m_buckets. I'm not sure how badly that will affect
> > > performance but it definitely wouldn't be as optimized.
> >
> > What about making the m_buckets volatile?  Wouldn't that
> > help?
>
> On second thought, a better approach would be to merge the
> m_locks[] and m_buckets[].
>
> The empty array should always have one node available--however
> the node is empty.  We synchronize on the first node in the
> bucket.  When we have something to put in the empty node, we
> set its values.
>
> That way we don't run into the problem of having a lock separate
> from what we really want to synchronize on.  I have a feeling
> that this is where the double-checked-locking-esque issues
> are coming from.
>
>
> --
> To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.o
rg>
> 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>


Mime
View raw message