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

David Holmes davidcholmes at aapt.net.au
Fri Sep 9 18:14:31 EDT 2011


If those longs are volatile then they must be atomically read and written as
per the Java language specification. It is up to the VM implementation to
ensure it provides such atomicity, even on ARM and PPC. In the worst-case
locking must be used. If the longs are not volatile then there is no
expectation of atomicity on any platform.

David Holmes
  -----Original Message-----
  From: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Rodrigo
Kumpera
  Sent: Saturday, 10 September 2011 5:42 AM
  To: Doug Lea
  Cc: Concurrency-interest at cs.oswego.edu
  Subject: Re: [concurrency-interest] LongAdder (was: StripedAdder)
andLongAdderTable





  On Sun, Jul 31, 2011 at 11:55 AM, 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.




  This class doesn't look to be 32bits safe as it does non-atomic load/store
of 64bits types.
  It certainly is not a problem on IA32 systems with TSO, but definitely an
issue ppc or arm.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20110910/86c3ae0b/attachment.html>


More information about the Concurrency-interest mailing list