Tests were done on an AWS 8 core instance (c1.xlarge), where we read or increment an array with 16 int variables, depending on whether we're locking in read mode or write mode.
The vertical axis represents the total number of operations (read operations + write operations) per milisecond, and the horizontal axis the number of threads.
Several configurations were tried, with 50%, 20%, 10%, 2%, 0.1%, and 0% Writes. For example, a configuration of 5 threads with 20% Writes means that each thread will do 4 read operations followed by one write operation and repeat. This has important implications, one of them is that, on average, for the case mentioned before (5 threads with 20% Writes) there is always a thread attempting a write operation.
As you can see from the plots, there is only a clear advantage for the ScalableReentrantRWLock if the number of Writes is reduced (at 10% Writes the StampedLock is much better). But these results change from system to system, for example, on my i7 720 Q laptop with 4 cores (8 threads) here is the plot for 10% Writes:
Conclusion, if you have a very low number of writes and high-contention, then you will probably see a significant performance improvement using ScalableReentrantRWLock, but if you have a high number of writes, then most likely not... the best is to try and measure with all the different locks for your specific application.
No comments:
Post a Comment