[concurrency-interest] Propagation ofsignalstonon-interruptedthread
vitalyd at gmail.com
Wed Nov 16 09:05:17 EST 2011
But AQS doesn't spin on the CAS so if it fails to lock it suspends the
thread. When you have lots of contention, it's usually the case that a
spinning CAS is less efficient than a mutex at that point.
In the example in this thread, the machine has 8 cores. 8 cas-spinning
threads still beats the lock. Once you increase the number of threads >
number of cpus, it loses because now you have runnable threads exceeding
core count and os has to context switch them. With a mutex, that's not the
case so it's more efficient.
On Nov 16, 2011 5:26 AM, "Ruslan Cheremin" <cheremin at gmail.com> wrote:
> 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
> > on a logarithmic scale) against number of threads. The
> > class is the same as in Brian's book. If you look at the blue line, it
> > down the more threads you have per AtomicPseudoRandom class, as the
> > probability of clashes increases. I could add a counter into that class
> > verify my assertion, but I'm pretty sure that the number of clashes will
> > 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.
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest