[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
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
> Activity Based Costing & Metering (ABC/M) – The Ultimate Feedback Loop
> Automated Performance Management starts with Software’s Self Observation
> Metering (Probes) Open API
> 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.)
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
More information about the Concurrency-interest