[concurrency-interest] regarding StampedLock

Dr Heinz M. Kabutz heinz at javaspecialists.eu
Mon Oct 15 11:34:12 EDT 2012

On 10/15/12 5:52 PM, Doug Lea wrote:
> On 10/15/12 10:46, Dr Heinz M. Kabutz wrote:
>> On my little dual core laptop, there is not too much starvation of 
>> neither the
>> readers nor the writers.  But on my 8-core server, the writers are 
>> almost
>> totally starved when I have a lot of readers running.  I'll format 
>> the results
>> and send them to you.
> It surprises me that the Phase-Fair antistarvation approximation is
> letting this happen. I don't see it in the tests I have for it,
> but if you sent me your code I could better check if this is
> a matter of improving the approximation or of a phenomenon somehow
> not covered by them.
Hi Doug,

my performance test is based on some starvation research I did in 2008 
regarding ReadWriteLock: http://www.javaspecialists.eu/archive/Issue165.html

However, this time I used your Point class, with a few modifications.  I 
removed the Math.sqrt() function, as I felt it might be too 
computationally significant.  Instead, I return some random 
multiplication that happens to always be zero.  However, it is not that 
obvious that it will always be zero, so I believe that the HotSpot 
compiler won't optimize it away.  It actually returns 1 if the test 
needed to resort to a pessimistic lock and 0 if it managed to read the 
values optimistically.  This way I can figure out how many of the reads 
were optimistically successful.

Big numbers mean high throughput and low numbers low throughput.  I 
basically try to call a reading and writing method from the given 
threads as often as I can within one second.

The performance results are interesting.  Reading always outperforms the 
ReadWriteLock, distanceFromOriginV2() approach, which I believe is how I 
would write the code.  It is the most elegant of the various options.

To those who were asking, yes, the reading was always more efficient in 
my tests than ReadWriteLock (third last column in my spreadsheet - 
StampedLock / ReadWriteLock read ratio).  In some cases it was almost 
4000x faster in the uncontended case.  That's a good reason to use it.

However, the writing it appears is not always faster.  If you look at 
the second last column in the spreadsheet (StampedLock / ReadWriteLock 
write ratio), you will see that if you have two readers and a lot of 
writers, then the ReadWriteLock is faster.  Since the StampedLock does 
not have a "fair" option (thank goodness for that!) we cannot compare 
those values, but they will definitely be worse than any of the values 
we see here (refer to 
http://www.javaspecialists.eu/archive/Issue165.html for a "fair" lock 

A point to note here: These results are on my 8-core dual processor 
server running Linux that I run most of my performance tests on.  The 
writers do not degrade as badly on my dual core MacBook Pro.  So this 
might be a phenomenon of my particular hardware.

The last column is also interesting.  It shows how many of the 
optimistic writes were successful.  The worst case was when we had one 
reader and one writer thread.  Only 0.54% of the time did we manage to 
get the right values with the optimistic read.  The second-worst was 
with 7 readers and 1 writer.  We only managed 7.98%

-------------- next part --------------
A non-text attachment was scrubbed...
Name: performance_results.pdf
Type: application/pdf
Size: 36572 bytes
Desc: not available
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20121015/c19bfb21/attachment-0001.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stampedlocktest.jar
Type: application/java-archive
Size: 14305 bytes
Desc: not available
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20121015/c19bfb21/attachment-0001.bin>

More information about the Concurrency-interest mailing list