On Mon, Aug 31, 2015 at 11:03 AM, Vladimir Ozerov <voze...@gridgain.com> wrote:
> 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. > I don't think this use-case is about performance. Yakov, can you jump in and remind us why we use the spin locks on Ignite instance stop? > > On Mon, Aug 31, 2015 at 6:41 PM, Dmitriy Setrakyan <dsetrak...@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 <voze...@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. > > > > > >
