[concurrency-interest] ArrayDeque constructor thread safety

Martin Buchholz Martin.Buchholz at Sun.COM
Sat Jul 22 16:38:14 EDT 2006

concurrency-interest-request at cs.oswego.edu wrote:
>>>On 7/21/06, R?mi Forax <forax at univ-mlv.fr> wrote:
>>>>To josh, perhaps i am tired, but for me,  allocateElements() always
>>>>a power of two size.
>>>Fair enough...
>>>>The other invariant is that head and tail must be
>>>>if the size is not empty, it seems to be the case.
>>>>So i continue to think that this implementation is valid.
>>>No.   Sun decided to make all collection "copy-constructors" robust to
>>>concurrent modification of the argument.  This is wise, in light of
>>>the fact that we now have true concurrent collections that cannot be
>>>globally locked.  So Martin's objection is valid.
>>sorry about my answer to martin, it was stupid.
>>ok, i understand now.
>>perhaps the third paragraph of java.util.Collection doc
>>can contain a line saying that copy constructor must rely on
>>the iterator of the collection taken as parameter.

If you look for tools that automatically find concurrency bugs
in Java, their No. 1 target was Vector(vector).  I was actually
more ambitious than relying on the iterator of the argument collection,
which is safe if the argument is a "concurrent" collection, but not
if it is a traditional "thread-safe" collection like Vector, since
the lock is not held while iterating.  The most reliable way to
get a snapshot of the elements in a collection with unknown concurrency
properties is to call its toArray method, and this is the
approach taken by Vector and ArrayList constructors.

ArrayDeque is still not safe in that sense.  ArrayDeque(vector)
may throw ConcurrentModificationException.  It's a bug.  Maybe.
Workaround: ArrayDeque(new ArrayList(vector))
Of course, we can easily fix ArrayDeque....if we don't care about
its performance.


More information about the Concurrency-interest mailing list