Re: [jetty-dev] SpinLock woes

[Greg Wilkins <gregw@xxxxxxxxxxx>]

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.