[concurrency-interest] LongAdder (was: StripedAdder) andLongAdderTable

Mohan Radhakrishnan mohanr at fss.co.in
Mon Aug 1 01:24:53 EDT 2011


Hi,

 

Hope this question doesn't divert the thread because it is too
simplistic. In this reply the reference to cores is only to highlight
the concurrency contention effect and how it is addressed. Right ? 

What is the difference in effect here between multiple threads in the
same CPU and multiple threads in different cores ? Is this one of the
key things I need to understand to start using the JSE 7 concurrency
utilities and FJ properly ?

 

>LongAdder vastly outperforms
>AtomicLong (sometimes by more than a factor of 100)
>when all cores are trying to update.  (Please let us know if
>you see different or surprising results.)



 

 

Thanks,

Mohan

 

________________________________

From: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf Of
Christian Vest Hansen
Sent: Sunday, July 31, 2011 10:09 PM
To: Doug Lea
Cc: Concurrency-interest at cs.oswego.edu
Subject: Re: [concurrency-interest] LongAdder (was: StripedAdder)
andLongAdderTable

 

Some interfaces for these things might be a good idea, as I can imagine
data grid libraries might want to provide distributed implementations.
Counter and CounterTable comes to mind as possible names.

On Sun, Jul 31, 2011 at 16:55, Doug Lea <dl at cs.oswego.edu> wrote:

It is much nicer not to have to decide ahead of time that
a program will have enough threads updating a variable
to need a class that can adaptively spread out contention.
So a reworked version of StripedAdder is now known as "LongAdder".
It is a variant of AtomicLong with a stripped-down API (suitable
only for adding and counting), that expands to use striping
when needed while avoiding noticeable overhead when not needed.

As the cost of contended atomic operations increases
(even as the cost of uncontended ones decreases on
some platforms), this will probably become a more commonly
useful class.

If you are curious, try out LongAdderDemo in the jsr166e tests.
On machines with more than a few cores LongAdder vastly outperforms
AtomicLong (sometimes by more than a factor of 100)
when all cores are trying to update.  (Please let us know if
you see different or surprising results.)

This class is currently in jsr166e but is targeted to
go into java.util.concurrent.atomic. APIs and implementations
are still subject to change.

Also, because it is likely to be among the more
common uses of LongAdders, we created AtomicLongTable,
that maintains a hash map of adders with arbitrary keys,
supporting usages including table.increment(key)

Links:
*  API specs:  http://gee.cs.oswego.edu/dl/jsr166/dist/jsr166edocs/
* jar file: http://gee.cs.oswego.edu/dl/jsr166/dist/jsr166e.jar
(compiled using Java7 javac).
* Browsable CVS sources:
http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/jsr166e/
* Browsable CVS test file sources:
http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/jsr166e/
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest at cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/concurrency-interest




-- 
Venlig hilsen / Kind regards,
Christian Vest Hansen.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20110801/1319398c/attachment-0001.html>


More information about the Concurrency-interest mailing list