[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.

http://opencore.jinspired.com/?page_id=3553#p23

http://williamlouth.wordpress.com/2010/01/05/user-level-metering-with-savepoints-changesets/ 


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