RFR: jsr166 jdk integration 2018-05 (original) (raw)
Paul Sandoz paul.sandoz at oracle.com
Fri May 18 21:25:42 UTC 2018
- Previous message: RFR: jsr166 jdk integration 2018-05
- Next message: RFR: jsr166 jdk integration 2018-05
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi,
My CME budget is definitely in the red now :-) but i would like to attempt to summarize the different positions and suggest a solution. If that does not get traction i believe a graceful retreat is in order.
We appear to be in two different philosophical camps with regards to the interpretation of modCount (i suspect what both camps believe is compatible with what CME specifies [*]).
One camp believes AbstractList.modCount should only (on a best-effort basis) be incremented on structural modifications that change the size (even if the size change cannot be externally observed, like the example Doug presents).
The other camp believes there are other forms of modification that perturb the list leading to incorrect results since those forms can affect yet to be traversed elements. It is argued that bulk operations such as replaceAll and sort fit in this category, regardless of the implementation.
I hope that is an accurate representation, and if that is so here is a rough proposal bring those camps together. The specification of AbstractList.modCount could be modified as follows:
/**
- The number of times this list has been structurally modified
- or globally modified.
- Structural modifications are those that change the size of the
- list, or otherwise perturb it in such a fashion that iterations in
- progress may yield incorrect results.
- Global modifications are those where the size may not change but the
- list is perturbed as a whole in such a fashion that iterations in progress
- may yield incorrect results.
Thoughts?
Paul.
[*] on CME
- Note that this exception does not always indicate that an object has
- been concurrently modified by a different thread. If a single
- thread issues a sequence of method invocations that violates the
- contract of an object, the object may throw this exception. For
- example, if a thread modifies a collection directly while it is
- iterating over the collection with a fail-fast iterator, the iterator
- will throw this exception.
Note that fail-fast behavior cannot be guaranteed as it is, generally
- speaking, impossible to make any hard guarantees in the presence of
- unsynchronized concurrent modification. Fail-fast operations
- throw {@code ConcurrentModificationException} on a best-effort basis.
- Therefore, it would be wrong to write a program that depended on this
- exception for its correctness: {@code ConcurrentModificationException}
- should be used only to detect bugs.
On May 16, 2018, at 4:04 PM, Doug Lea <dl at cs.oswego.edu> wrote:
Sorry Stuart, but I'm joining the no-modCount barrage. To pick on the main issue... On 05/16/2018 05:21 PM, Stuart Marks wrote: Suppose that a replaceAll() on another thread occurs, and that this is allowed. Does the application care whether the eventual printout contains partly new values and partly old values? How can you tell? It seems to me that this is more likely a programming error than a valid use case. There are many data-races that are never detected via CME. CME was designed to trap only some of them (and even at that, only heuristically because modCount operations are not strictly ordered). ModCount mechanics only deal with insertions and removals. Failing to catch a race in replaceAll is no different than failing to catch one with multiple concurrent setValues. It might be "nice" to adjust modCount on any operation that might contribute to a datarace, but no reason to single out replaceAll. Having said this, I don't think that anything in the spec (vs default implementation) prohibits an implementation of replaceAll from removing and then re-inserting each element, in which case an implementation would modify modCounts. -Doug
- Previous message: RFR: jsr166 jdk integration 2018-05
- Next message: RFR: jsr166 jdk integration 2018-05
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]