On Tue, Aug 23, 2016 at 9:17 AM, Martin Buchholz <marti...@google.com> wrote:
> I didn't see this thread before updating the bug. > > I think this is Not a Bug, because """The current atomic addAll is a > tradeoff; it's efficient, but at the cost of potential loss of concurrency > if the other collection is slow. It's reasonable for a subclass to override > addAll to add elements eagerly and non-atomically.""" > > OTOH it would be reasonable to document the atomicity of the > implementation in CLD and CLQ as @implNote. > Right now I'm even back-pedaling on that. Unless there's an important use case where atomicity of addAll matters, it's not worth the confusion to document that some particular implementation is atomic. The aim of that code was efficiency, not atomicity. In fact, choosing some batch size and adding in chunks, I/O buffer style, may be a better choice.
