8178956: Misleading description of arguments to accumulator function called by LongAccumulator
Reviewed-by: martin, psandoz, dholmes, darcy
This commit is contained in:
parent
a2667824fb
commit
8e1db99fd6
@ -56,11 +56,13 @@ import java.util.function.DoubleBinaryOperator;
|
|||||||
*
|
*
|
||||||
* <p>The supplied accumulator function should be side-effect-free,
|
* <p>The supplied accumulator function should be side-effect-free,
|
||||||
* since it may be re-applied when attempted updates fail due to
|
* since it may be re-applied when attempted updates fail due to
|
||||||
* contention among threads. The function is applied with the current
|
* contention among threads. For predictable results, the accumulator
|
||||||
* value as its first argument, and the given update as the second
|
* function should be commutative and associative within the floating
|
||||||
* argument. For example, to maintain a running maximum value, you
|
* point tolerance required in usage contexts. The function is applied
|
||||||
* could supply {@code Double::max} along with {@code
|
* with an existing value (or identity) as one argument, and a given
|
||||||
* Double.NEGATIVE_INFINITY} as the identity. The order of
|
* update as the other argument. For example, to maintain a running
|
||||||
|
* maximum value, you could supply {@code Double::max} along with
|
||||||
|
* {@code Double.NEGATIVE_INFINITY} as the identity. The order of
|
||||||
* accumulation within or across threads is not guaranteed. Thus, this
|
* accumulation within or across threads is not guaranteed. Thus, this
|
||||||
* class may not be applicable if numerical stability is required,
|
* class may not be applicable if numerical stability is required,
|
||||||
* especially when combining values of substantially different orders
|
* especially when combining values of substantially different orders
|
||||||
|
@ -59,11 +59,12 @@ import java.util.function.LongBinaryOperator;
|
|||||||
* applicable to functions for which the order of accumulation does
|
* applicable to functions for which the order of accumulation does
|
||||||
* not matter. The supplied accumulator function should be
|
* not matter. The supplied accumulator function should be
|
||||||
* side-effect-free, since it may be re-applied when attempted updates
|
* side-effect-free, since it may be re-applied when attempted updates
|
||||||
* fail due to contention among threads. The function is applied with
|
* fail due to contention among threads. For predictable results, the
|
||||||
* the current value as its first argument, and the given update as
|
* accumulator function should be associative and commutative. The
|
||||||
* the second argument. For example, to maintain a running maximum
|
* function is applied with an existing value (or identity) as one
|
||||||
* value, you could supply {@code Long::max} along with {@code
|
* argument, and a given update as the other argument. For example,
|
||||||
* Long.MIN_VALUE} as the identity.
|
* to maintain a running maximum value, you could supply {@code
|
||||||
|
* Long::max} along with {@code Long.MIN_VALUE} as the identity.
|
||||||
*
|
*
|
||||||
* <p>Class {@link LongAdder} provides analogs of the functionality of
|
* <p>Class {@link LongAdder} provides analogs of the functionality of
|
||||||
* this class for the common special case of maintaining counts and
|
* this class for the common special case of maintaining counts and
|
||||||
|
Loading…
x
Reference in New Issue
Block a user