[concurrency-interest] LongAdder (was: StripedAdder) and LongAdderTable

William Louth (JINSPIRED.COM) william.louth at jinspired.com
Tue Aug 2 06:59:17 EDT 2011

Wanted to add that I see named thread counters as being the only 
realistically option for greater instrumentation & observation in the 
concurrent package without having to expose more superfluous methods in 
the interfaces which anyway would not be consistent and constitute 
causality. In fact I think we need to see more of this in all libraries 
especially container like interfaces which offer dynamic capabilities. 
For example in interacting w/ a map it would be great to be able to 
expose resizing.

With savepoint & changeset support this has many cool possibilities.



On 31/07/2011 21:22, William Louth (JINSPIRED.COM) wrote:
> I am currently writing up a proposal (will be posted on blog next week 
> hopefully) for having an intrinsic (long) counter data type in the 
> Java that would be thread local (though not access through this 
> interface) and optimized by the JVM whilst affording the ability to 
> introspect the current set of named counters in the JVM as well as 
> their instance (and value) on a per thread basis (preferably within 
> the thread itself) via an API. I think we should be encouraging 
> developers to move away from process level JMX like counters and 
> instead thread specific & event based (without state) which could be 
> in turn be accessed at a process level if need be but more so at the 
> thread level and from a caller/chain perspective forming a foundation 
> for the ultimate feedback loop between callers and callees.
> This a part of a much bigger proposal for software activity metering 
> to be a core aspect of the runtime, library and possibly language (via 
> event counters)
> OpenCore Metering Runtime Actors
> http://opencore.jinspired.com/?p=1888
> Activity Based Costing & Metering (ABC/M) – The Ultimate Feedback Loop
> http://opencore.jinspired.com/?p=4052
> Automated Performance Management starts with Software’s Self Observation
> http://opencore.jinspired.com/?p=2709
> Metering (Probes) Open API
> http://opencore.jinspired.com/?page_id=715
> On 31/07/2011 20:56, Doug Lea wrote:
>> On 07/31/11 12:39, Christian Vest Hansen wrote:
>>> 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.
>> I had proposed this, but talked myself out of it.
>> The APIs are tied to a particular scalar type (long),
>> and might grow to include others (in particular, a
>> DoubleAdder class). It may be that the only
>> commonality is that they extend java.lang.Number. Which
>> we declared for the AtomicX classes, but even that was not
>> obviously helpful.
>>> On Sun, Jul 31, 2011 at 16:55, Doug Lea <dl at cs.oswego.edu
>>> <mailto:dl at cs.oswego.edu>> wrote:
>>> Also, because it is likely to be among the more
>>> common uses of LongAdders, we created AtomicLongTable,
>> Oops. I meant LongAdderTable. (The names changed several times
>> times before check-in.)
>> -Doug
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

More information about the Concurrency-interest mailing list