[concurrency-interest] Propagation ofsignalstonon-interruptedthread

Vitaly Davidovich 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
> 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.
> >>
> >>
> >
>
> _______________________________________________
> 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/20111116/bbd0c71b/attachment.html>


More information about the Concurrency-interest mailing list