Locks are bad for performance, but still they are good fit for some scenario.
In this post i will review java Read/Write lock and alternate implementation of fast Read/Write lock
What is Readers-Writer lock
Lets do quick re-cap of read/write lock.
As name suggest it is shared lock , it is shared between readers/writers. So you can have either reader(s) or writer. You can have multiple readers or one writer active at any given point of time. So it is very good fit for the case where number of read operation is more than write.
What is the issue with Java RW lock
By design only reader(s) or writer can be active at any given point of time, so it will cause starvation when contention is high.
Advance RW lock will have additional features like
With all these issues rw locks are still used.
How does RW lock perform.
Lets try to measure rw lock performance under different scenario
Details of problem that will be used for testing
Read/Write to Hashmap, writer threads adds 1 Million entry to map and reader tries to read those value back, for write operation Write lock is used and for read operation Read lock is used.
I will try to test java rw lock under no-contention and gradually try to increase contention to see how it performs.
Legend to read graph
1W - One writer
1W-1R - One writer & One reader
1W-2R - One write & Two reader
Writer Performance
X Axis - Writer/reader Threads
Y Axis - Time to 1 Milli entry
Case when there is "1 Writer & 1 Reader" shows wired number on my system, i will ignore that for comparison.
When there is no contention writer takes around 73 ms and as we add more reader threads contention increases, it starts to slow down, in my example when total thread count reaches to 4 performance drops by 10 times. That is big drop for "1Writer-3Reader" scenario, just think what will happen if more readers are added.
Writer Throughput
Lets have look at throughput
X Axis - Writer/reader Threads
Y Axis - Throughput/Sec
I will ignore case "1W-1R"
Throughput also takes big hit under contention, it falls from sky to roof, for 1 writer throughput is 14 million and once total thread count reaches to 4 throughput drops to 1.4 million which is 90% less.
Writer is just one part of RW lock, lets look at the performance of reader.
Reader Performance
X Axis - Writer/reader Threads
Y Axis - Time to add 1 Million entry
Performance degrade trend continues in readers also.
Reader throughput also takes hit under contention.
Readers without writer contention
This scenario is very realistic because
90% + times application only reads the data and it is the performance of readers threads that will matter most by the end of day. Lets have look at performance when only readers are active.
In this test data in hashmap was pre-populated and only readers threads were executing.
Numbers now looks real :-) .
It takes more time to read data as number of readers increase, same thing is observed for throughput also, it drops.
Alternate Reader/Writer Lock
Lets compare alternate implementation of RW lock
Readers without writer contention
Fast Lock outperforms java ReadWriteLock in both the test.
In the first test, time taken to read is almost flat with Fast RW Lock and for java based it is going up like stock price as we keep on adding more readers thread.
In throughput test java rw lock starts from 28 million and it drops to 1.6 million, that is 95% drop.
Fast rw lock starts from 58 million and drops to 34 million, that is around 40% drop.
Under heavy contention(i.e 4 readers), java readerwriter lock is around 20X times slow, that looks like comparing apple vs orange, but test result shows that.
So for readers new lock looks great, lest measure with writer.
Writer Performance - Java RW vs Fast RW
Fastlock performs better than java RW lock under contentions
Reader Performance - Java RW vs Fast RW
What makes FastRW lock fast
Now lets understand why new read/write lock is fast.
RW lock that i have used for testing is an implementation of SeqLock. SeqLock is very common in linux world, it provide parallelism for readers & writer. Reader never blocks writer & reader uses optimistic approach to read the data.
Readers in seqlock never update any sate in ReadWrite lock and thus reduces cpu cache traffic,so just load operation is involved for reading data.
So in nutshell it provides
With so much of benefit i am sure you will never use java RW lock!
Conclusion
SeqLock are very good alternative for reader/writer lock and especially in multicore world where we are use new technique to get best out of processor. Someday java will add support for seqlock.
Code is available @ GitHub for your reference.
In this post i will review java Read/Write lock and alternate implementation of fast Read/Write lock
What is Readers-Writer lock
Lets do quick re-cap of read/write lock.
As name suggest it is shared lock , it is shared between readers/writers. So you can have either reader(s) or writer. You can have multiple readers or one writer active at any given point of time. So it is very good fit for the case where number of read operation is more than write.
What is the issue with Java RW lock
By design only reader(s) or writer can be active at any given point of time, so it will cause starvation when contention is high.
Advance RW lock will have additional features like
- Priority - for eg writer has more priority than readers or otherwise
- Fairness - This can be based on waiting time
With all these issues rw locks are still used.
How does RW lock perform.
Lets try to measure rw lock performance under different scenario
Details of problem that will be used for testing
Read/Write to Hashmap, writer threads adds 1 Million entry to map and reader tries to read those value back, for write operation Write lock is used and for read operation Read lock is used.
I will try to test java rw lock under no-contention and gradually try to increase contention to see how it performs.
Legend to read graph
1W - One writer
1W-1R - One writer & One reader
1W-2R - One write & Two reader
Writer Performance
X Axis - Writer/reader Threads
Y Axis - Time to 1 Milli entry
Case when there is "1 Writer & 1 Reader" shows wired number on my system, i will ignore that for comparison.
When there is no contention writer takes around 73 ms and as we add more reader threads contention increases, it starts to slow down, in my example when total thread count reaches to 4 performance drops by 10 times. That is big drop for "1Writer-3Reader" scenario, just think what will happen if more readers are added.
Writer Throughput
Lets have look at throughput
X Axis - Writer/reader Threads
Y Axis - Throughput/Sec
I will ignore case "1W-1R"
Throughput also takes big hit under contention, it falls from sky to roof, for 1 writer throughput is 14 million and once total thread count reaches to 4 throughput drops to 1.4 million which is 90% less.
Writer is just one part of RW lock, lets look at the performance of reader.
Reader Performance
X Axis - Writer/reader Threads
Y Axis - Time to add 1 Million entry
Performance degrade trend continues in readers also.
Reader Throughput
Reader throughput also takes hit under contention.
Readers without writer contention
This scenario is very realistic because
- Mostly writer thread will populate data at application start up time
- Or based on some write event to update data incrementally
90% + times application only reads the data and it is the performance of readers threads that will matter most by the end of day. Lets have look at performance when only readers are active.
In this test data in hashmap was pre-populated and only readers threads were executing.
Numbers now looks real :-) .
It takes more time to read data as number of readers increase, same thing is observed for throughput also, it drops.
Alternate Reader/Writer Lock
Lets compare alternate implementation of RW lock
Readers without writer contention
Fast Lock outperforms java ReadWriteLock in both the test.
In the first test, time taken to read is almost flat with Fast RW Lock and for java based it is going up like stock price as we keep on adding more readers thread.
In throughput test java rw lock starts from 28 million and it drops to 1.6 million, that is 95% drop.
Fast rw lock starts from 58 million and drops to 34 million, that is around 40% drop.
Under heavy contention(i.e 4 readers), java readerwriter lock is around 20X times slow, that looks like comparing apple vs orange, but test result shows that.
So for readers new lock looks great, lest measure with writer.
Writer Performance - Java RW vs Fast RW
Fastlock performs better than java RW lock under contentions
Reader Performance - Java RW vs Fast RW
What makes FastRW lock fast
Now lets understand why new read/write lock is fast.
RW lock that i have used for testing is an implementation of SeqLock. SeqLock is very common in linux world, it provide parallelism for readers & writer. Reader never blocks writer & reader uses optimistic approach to read the data.
Readers in seqlock never update any sate in ReadWrite lock and thus reduces cpu cache traffic,so just load operation is involved for reading data.
So in nutshell it provides
- Less cpu cache traffic
- Readers never block writer
- Reader never changes state of lock, no expensive store operation
- Readers can slow down if write frequency is very high
- Writer always get priority
With so much of benefit i am sure you will never use java RW lock!
Conclusion
SeqLock are very good alternative for reader/writer lock and especially in multicore world where we are use new technique to get best out of processor. Someday java will add support for seqlock.
Code is available @ GitHub for your reference.
No comments:
Post a Comment