On 06/13/2013 10:44 AM, Paul Sandoz wrote:
On Jun 13, 2013, at 10:15 AM, Remi Forax <fo...@univ-mlv.fr> wrote:
On 06/13/2013 09:51 AM, Paul Sandoz wrote:
On Jun 13, 2013, at 7:28 AM, Mike Duigou <mike.dui...@oracle.com> wrote:
I have updated my webrev with Remi's improvements and some other improvements
to the fast-fail concurrent modification checking.
Revised webrev:
http://cr.openjdk.java.net/~mduigou/JDK-8016446/1/webrev/
The approach we have taken for bulk traversal of fail-fast spliterators and
ArrayList/Vector is to check the mod count at the end of the loop. I think we
should be consistent with those.
Paul.
Hi Paul,
ArrayList.forEach() does the modCount check at each step.
Doh, yes, i mis read the logic in the for statement in ArrayList/Vector.
There is a difference between an Iterator/forEach and a spliterator/stream,
with a stream you know that the called lambdas will not interfere and mutate
the source collection.
You do? I don't think there is any conceptual difference between the following
w.r.t. interference:
ArrayList l = ...
l.stream().filter(...).forEach(e -> l.add(e));
l.spliterator().forEachRemaining(e -> l.add(e));
and:
ArrayList l = ...
l.forEach(e -> l.add(e));
l.iterator().forEachRemaining(e -> l.add(e));
Of course we have (or will have) strong wording saying don't implement
interfering lambdas, but we still have to check for co-modification in the
traversal methods of ArrayList spliterator.
Isn't it because if you remove an element from an ArrayList while
iterating you can see a stale value ?
While with a HashMap, if you have only one thread, you can not see a
stale entry ?
So a spliterator on HashMap can only check the modCount at the end
unlike the one on ArrayList that need to check at each step.
So we are still inconsistent between Spliterator.forEachRemaining and
Iterator.forEachReamining/Collection.forEach.
Paul.
Rémi
