[concurrency-interest] LongAdder with custom behavior?

Martin Buchholz martinrb at google.com
Sat Dec 2 15:17:03 EST 2017

On Sat, Dec 2, 2017 at 5:41 AM, Doug Lea via Concurrency-interest <
concurrency-interest at cs.oswego.edu> wrote:

> On 12/01/2017 02:18 AM, Carl Mastrangelo via Concurrency-interest wrote:
> >
> > I would like sumThenReset to tally up all the mutations, and reset
> > the counter back to zero without dropping mutations.  This would make
> > it so I call sumThenReset later, and pick up any mutations I missed.
> It sounds like you are looking for a SNZI (scalable non-zero indicator).
> (Google it). We ought to consider supplying one.
> >
> > the implementation of sumThenReset does two volatile operations on
> > each Cell.value.  First it reads, followed by setting it to zero.
> > Why doesn't it use getAndSet on the value?
> Yes; thanks. This should usually be faster. Changes are now in jsr166
> CVS and should some day propagate.

So we've implemented this optimization and it might provide the concurrency
control Carl is looking for, but we're reluctant to promise anything in the
spec along these lines.  After these changes, sumThenReset can be used to
"drain" a "queue" where there is no data associated with each queue
element, only a total count of elements.  But the name of the method is
wrong for that use case, and it is likely to be misused - most queue
elements do actually need to provide some data.  I'm reminded of the Unix
signal fiasco - signals were originally designed to be data free, and
duplicates could be discarded, but I think that was a mistaken design, and
now we have siginfos that could be lost if signals arrive concurrently.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20171202/1135b0cd/attachment.html>

More information about the Concurrency-interest mailing list