[concurrency-interest] regarding StampedLock
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
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
>>> 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/**
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest