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

David Holmes davidcholmes at aapt.net.au
Mon Aug 1 03:31:56 EDT 2011


Hi Mohan,

Yes this is only to highlight the contention effects that concurrent updates
on multiple cores can produce.

Multiple threads on the same CPU/core can never contend with each other at
the level of the atomic instruction. A thread can get a failed CAS of
course, because it was context switched out and another thread updated the
value, but that is "contention" at the logical level, not at the hardware
level.

Performance under contention is a key consideration in concurrent programs,
but the goal should always be to remove the contention, not just to find
mechanisms that perform better under contention.

David Holmes

-----Original Message-----
From: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Mohan
Radhakrishnan
Sent: Monday, 1 August 2011 3:25 PM
To: concurrency-interest
Subject: Re: [concurrency-interest] LongAdder (was:
StripedAdder)andLongAdderTable


  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/c2dc4829/attachment.html>


More information about the Concurrency-interest mailing list