[concurrency-interest] High performance clock/counter

Andrew Haley aph at redhat.com
Sun Apr 25 12:54:43 EDT 2010


On 04/24/2010 12:21 PM, Doug Lea wrote:
> On 04/23/10 18:10, Peter Veentjer wrote:
> 
>> I'm looking for a high performance counter to be used inside an STM.
>>
> 
> We've considered putting some counter-based classes
> in j.u.c., but supporting the range of needs and tradeoffs
> doesn't seem amenable to a small set of solutions.
> Among the possibilities:
> 
> * If you are willing to live with approximate results
> on reads, then striping can work well (as in Cliff Click's
> high-scale lib -- http://sourceforge.net/projects/high-scale-lib/)
> 
> * For accurate reads, See Herlihy & Shavit's book for discussion
> of tree-based  counters and counting networks, that entail a fair
> amount of overhead.
> 
> * If you only need to detect special properties/values
> (non-zero in particular) see SNZI (Scalable non-zero indicators)
> by Mark Moir's group -- http://research.sun.com/scalable/pubs/index.html,
> that was developed mainly for STM support.
> 
> * For some problems involving contended counters, the
> best solutions often entail reducing contention pressure
> by engaging in some domain-specific alternative action
> when an attempted CAS on a simple variable fails.

All of this reminds me of something I was meaning to ask.

None of the counters suitable for use in an implementation of an
algorithm like TL2 are very nice: you either end up with high
contention on a single counter variable or something rather
heavyweight.  Would it make sense for the hardware to provide global
high-performance counters?  I'm thinking of a counter that could be
handled very efficiently by some sort of low-latency broadcast
protocol.

Andrew.


More information about the Concurrency-interest mailing list