[concurrency-interest] High performance clock/counter

Peter Veentjer alarmnummer at gmail.com
Fri Apr 23 18:54:33 EDT 2010


I have been experimenting with the Counter of Cliff (the
ConcurrentAutoTable) and changed
the following:

 /** {@link #add} with +1 */
  public void increment()   { add_if_mask( 1L,0); }

to:

 /** {@link #add} with +1 */
  public long increment()   { return add_if_mask( 1L,0)+1; }

I do get good increments but once and a while this function returns a
value smaller than the previous version.  So apparently this is not
the way to go.


On Sat, Apr 24, 2010 at 12:10 AM, Peter Veentjer <alarmnummer at gmail.com> wrote:
> High All,
>
> I'm looking for a high performance counter to be used inside an STM.
>
> Atm I use an AtomicLong, but if the number threads increase, the
> performance drops, example:
>
> Thread count: 1
> Update transactions/second: 74,149,986.633
> Update transactions/second: 74,149,986.633 per core
>
> Thread count: 2
> Update transactions/second: 22,864,414.996
> Update transactions/second: 11,432,207.498 per core
>
> Thread count: 4
> Update transactions/second: 21,958,871.971
> Update transactions/second: 5,489,717.993 per core
>
> Thread count: 8
> Update transactions/second: 25,207,393.631
> Update transactions/second: 3,150,924.204 per core
>
> I have a machine with 8 cores.
>
> I already use a 'relaxed' increment, it is allowed that concurrent
> increments on the clock,
> return the same value. So I'm using the following:
>
> long writeVersion;
> if (strict) {
>    writeVersion = clock.incrementAndGet();
> } else {
>    long value = clock.get();
>    writeVersion = value+1;
>    clock.compareAndSet(value, writeVersion);
> }
>
> The performance numbers above are creating using the strict = false.
>
> I was also playing with the Counter of the high scale lib from Cliff Click,
> and the increment is amazingly fast (it gets faster the more cores I
> throw at it). But
> the big problem is that the increment doesn't return a value, and I need this
> to determine the writeversion of the transaction. If I do a
> counter.get after the
> increment, the performance drops far under the AtomicLong with the
> relaxed increment.
>
> So does someone know about a library/approach to solve this situation?
>



More information about the Concurrency-interest mailing list