[concurrency-interest] regarding StampedLock

Stanimir Simeonoff stanimir at riflexo.com
Mon Oct 15 12:37:06 EDT 2012


Few notes about the test:
- java.util.Random is thread safe and still uses one CAS per random int and
a double needs 2 ints. While the CAS will be uncontended the store buffers
are to be always empty while entering the "lock()". You may simplify the
test to use ints only.
- IMO, numberOfPessimisticReads/numberOfLockAcquisitions should not be
volatile either as they don't need so and writing them also flushes the CPU
buffers.

Stanimir

On Mon, Oct 15, 2012 at 6:34 PM, Dr Heinz M. Kabutz <
heinz at javaspecialists.eu> wrote:

> 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<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<http://www.javaspecialists.eu/archive/Issue165.html>for a "fair" lock experiment).
>
> 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%
>
>
>
>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20121015/d7f75d13/attachment.html>


More information about the Concurrency-interest mailing list