commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <>
Subject RE: [Collections] StaticBucketMap not thread safe
Date Tue, 25 Jun 2002 20:28:40 GMT
> From: Berin Loritsch [] 
> > From: Jack, Paul []
> > 
> > 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:   <>
For additional commands, e-mail: <>

View raw message