Re: [jetty-dev] SpinLock woes

[Greg Wilkins <gregw@xxxxxxxxxxx>]

Simone,

I re-ran my benchmarks with a simple body:

        long c=0;
        boolean even;
        try (Locker.Lock l = state.lock.lock())
        {
            c=state.count;
            even=state.count%2==0;
            state.count=++state.count%10000;
        }
        return even?c:-c;

The results I get are:

Benchmark                              Mode  Samples         Score   Error  Units
o.e.j.b.LockBenchmark.testLock        thrpt        2  37241687.930 ±   NaN  ops/s
o.e.j.b.LockBenchmark.testSpinLock    thrpt        2  45032559.188 ±   NaN  ops/s
o.e.j.b.LockBenchmark.testSync        thrpt        2  43886899.163 ±   NaN  ops/s

So for uncontested locks, I'm still seeing a benefit for SpinLock.

cheers

On 9 June 2015 at 17:36, Greg Wilkins <gregw@xxxxxxxxxxx> wrote:

On 9 June 2015 at 04:57, Simone Bordet <sbordet@xxxxxxxxxxx> wrote:

I rewrote the JMH benchmark to test a simple synchronized block against ReentrantLock against SpinLock. The code inside the lock is BlackHole.consumeCPU(128).

Simone,

I don't think that is a realistic test for SpinLock.

The intention of SpinLock is to replace a lock free algorithm that could work on an AtomicReference<State>, but the state machine has just got a little to complex to represent in a single state variable.  Typical use will still be a state variable, but with perhaps a counter or additional boolean to represent nested states.

BlackHole.consumeCPU(128) is not a realistic load for this.  Perhaps BlackHole.consumeCPU(5) and any more is indicating a use that SpinLock should not be used in that case. Also  spinning the CPU is not what should be happening in a SpinLock. It should be memory accesses: gets, tests and sets.   So I think it is best to test with a realistic code test and set of 2 fields like my original benchmark did, which showed a significant advantage to the spinlock for the uncontested case.

cheers

--

Greg Wilkins <gregw@xxxxxxxxxxx>  - an Intalio.com subsidiary
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.

--

Greg Wilkins <gregw@xxxxxxxxxxx>  - an Intalio.com subsidiary
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.