> On 31 Jan 2017, at 16:16, Martin Buchholz <[email protected]> wrote:
>
>
>
> On Tue, Jan 31, 2017 at 4:03 PM, Paul Sandoz <[email protected]
> <mailto:[email protected]>> wrote:
>>
>> ConcurrentSkipListSet
>> —
>>
>> 76 * <p>Bulk operations that add, remove, or examine multiple elements,
>> 77 * such as {@link #addAll}, {@link #removeIf} or {@link #forEach},
>> 78 * are <em>not</em> guaranteed to be performed atomically.
>> 79 * For example, a {@code forEach} traversal concurrent with an {@code
>> 80 * addAll} operation might observe only some of the added elements.
>>
>> toArray was removed, and it’s not atomic. Same for many other cases.
>>
>> We tried to maintain complete lists of non-atomic operations, but those
>> became stale as new methods got added to superclasses/superintterfaces.
>> Even toString is non-atomic! Give up or be pedantically exhaustive?
>
> The removal “toArray” is arguably a specification change, and it’s removal
> could be misconstrued as implying it is now atomic. So i would just leave the
> existing documentation as is.
>
> But ... the problem is that the docs implied that all the other operations
> *were* guaranteed atomic, which became untrue when y'all added forEach and
> friends. That is, this is supposed to be a doc bug fix. And toString was
> always missing from the list.
>
Is not toString a bulk operation that examines multiple elements?
I know toArray fits within that remit, but i just prefer to keep to the
original documentation, since the change might be incorrectly perceived as a
change in behaviour.
It’s a very mild objection, please override if you feel i am being overly
conservative here!
Paul.
> * Additionally, the bulk operations {@code addAll},
> * {@code removeAll}, {@code retainAll}, {@code containsAll},
> * {@code equals}, and {@code toArray} are <em>not</em> guaranteed
> * to be performed atomically. For example, an iterator operating
>
>
