Vova, can you please share your benchmark? That was long time ago and I recall that I got better results in more complex benchmarks than jmh one.
However, I am quiet excited with your idea to change implementation to striped RW locks: * busy state - we do tryLock() on random read lock * blocked state - since this is very rare, we can acquire write locks on each stripe. Is this what you've meant? -- Yakov Zhdanov, Director R&D *GridGain Systems* www.gridgain.com 2015-08-31 21:06 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org>: > 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. > > > > > > > > > >
