[concurrency-interest] ArrayDeque constructor thread safety
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.
>>>>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
More information about the Concurrency-interest