ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Ozerov <voze...@gridgain.com>
Subject Re: GridSpinBusyLock performance
Date Mon, 31 Aug 2015 18:03:01 GMT
Exactly, we use it primarily as "busy" lock, i.e. lots of concurrent
readers with writer blocking everything on node stop. But it doesn't
outperform regular ReentrantReadWriteLock actually.

On Mon, Aug 31, 2015 at 6:41 PM, Dmitriy Setrakyan <dsetrakyan@apache.org>
wrote:

> I don't recall exactly, but from what I remember, there were other benefits
> to the spin-lock approach. Don't we use some characteristics of this lock
> to properly shut down the system?
>
> D.
>
> On Mon, Aug 31, 2015 at 5:24 AM, Vladimir Ozerov <vozerov@gridgain.com>
> wrote:
>
> > Igniters,
> >
> > We have two pretty strange constructs: GridSpinReadWriteLock and base on
> it
> > GridSpinBusyLock.
> > As I understand it was an effort to create more performant RWLock than
> > ReentrantReadWriteLock
> > for cases when wrtie locks are very unlikely.
> >
> > As busy lock concept is also used in some sensitive places of "platforms"
> > module, I measured performance of read lock-unlock cycles for both
> > ReentrantReadWriteLock
> > and GridSpinReadWriteLock using JMH.
> >
> > Our implementation doesn't offer any perform benefits comparing to
> > ReentrantReadWriteLock, their performance are almost equal. This makes
> > sense, because essentailly both locks just CASes on a shared variable to
> > obtain the read lock. Looks like we can safely remove these "spinners"
> and
> > use ReentrantReadWriteLock instead.
> >
> > More serious perfomance gain can be achieved if we stripe the lock (e.g.
> > like it is done in LongAdder) thus decreasing contention on shared
> > variables. Quick experiments shown 5x throughput increase for read
> > lock-unlock cycles when lock is striped.
> >
> > Thoughts?
> >
> > Vladimir.
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message