[concurrency-interest] Propagation ofsignalstonon-interruptedthread

Ruslan Cheremin cheremin at gmail.com
Wed Nov 16 05:23:03 EST 2011


But it should be also more clashes inside AQS.compareAndSetState() --
which called on fast path of ReentrantLock.lock(). Or you want to say,
that ReentrantLock version has longer code path, so it has effect of
back off, slowering execution down a bit, and so reducing actual
contention on CASed variables?

2011/11/16 Dr Heinz M. Kabutz <heinz at javaspecialists.eu>:
> I would imagine that there could be quite a few times that the CAS has to be
> retried until it is successful.  Look at the bottom right graph -
> "Throughput - Thirty-two Threads" - this is now throughput (normalized and
> on a logarithmic scale) against number of threads.  The AtomicPseudoRandom
> class is the same as in Brian's book.  If you look at the blue line, it dips
> down the more threads you have per AtomicPseudoRandom class, as the
> probability of clashes increases.  I could add a counter into that class to
> verify my assertion, but I'm pretty sure that the number of clashes will be
> substantial.
>
> Regards
>
> Heinz
> --
> Dr Heinz M. Kabutz (PhD CompSci)
> Author of "The Java(tm) Specialists' Newsletter"
> Sun Java Champion
> IEEE Certified Software Development Professional
> http://www.javaspecialists.eu
> Tel: +30 69 72 850 460
> Skype: kabutz
>
>
> On 11/15/11 11:03 PM, Ruslan Cheremin wrote:
>>
>> It seems very strange to me -- how can value updated by many threads
>> guarded by ReentrantLock outperform just simple CAS? As far, as I
>> know, ReentrantLock on fast path still has at least one CAS + value
>> update itself, it must be slower then just one CAS in an way.
>>
>>
>



More information about the Concurrency-interest mailing list