[concurrency-interest] High performance clock/counter
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
More information about the Concurrency-interest