[concurrency-interest] LongAdder (was: StripedAdder) andLongAdderTable
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.
From: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Rodrigo
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)
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...
More information about the Concurrency-interest