[concurrency-interest] Why "fast path" is faster than full enq in AQS

Martin Buchholz martinrb at google.com
Sat Jan 6 10:39:12 EST 2018


Alternatively: initializeSyncQueue is now a separate cold-code method.

(All of this is unlikely to matter much)

On Sat, Jan 6, 2018 at 2:28 AM, David Holmes via Concurrency-interest <
concurrency-interest at cs.oswego.edu> wrote:

> The old structure was intended to be more amenable to inlining the
> fast-path code IIRC. The new code doesn’t bother AFAICS.
>
>
>
> David
>
>
>
> *From:* wen [mailto:nathanielwen at 163.com]
> *Sent:* Saturday, January 6, 2018 7:10 PM
>
> *To:* dholmes at ieee.org
> *Cc:* 'Concurrency-interest' <concurrency-interest at cs.oswego.edu>
> *Subject:* Re: [concurrency-interest] Why "fast path" is faster than full
> enq in AQS
>
>
>
> The full enq will loop only once when there is no contention and the tail
> isn't null. The reason why "fast-path" is faster is because in most cases
> the tail isn't null. So "if (tail != null)" is more efficient than "if
> (tail == null) ... else ..." in this very case, am I right?
>
> On 01/5/2018 20:00,David Holmes<davidcholmes at aapt.net.au>
> <davidcholmes at aapt.net.au> wrote:
>
> The fast path just does a direct enqueue to the existing tail. The enq(),
> in the worst case, has to initialize the queue, and in general deals with
> contention due to concurrent enqueue attempts.
>
>
>
> The code is different now.
>
>
>
> David
>
>
>
> *From:* Concurrency-interest [mailto:concurrency-interest-
> bounces at cs.oswego.edu] *On Behalf Of *??? via Concurrency-interest
> *Sent:* Friday, January 5, 2018 5:34 PM
> *To:* dholmes at ieee.org
> *Cc:* 'Concurrency-interest' <concurrency-interest at cs.oswego.edu>
> *Subject:* Re: [concurrency-interest] Why "fast path" is faster than full
> enq in AQS
>
>
>
> My JDK version is 1.8
>
>
>
> private Node addWaiter(Node mode) {
>
>     Node node = new Node(Thread.currentThread(), mode);
>
>     // Try the fast path of enq; backup to full enq on failure
>
>     Node pred = tail;
>
>     if (pred != null) {
>
>         node.prev = pred;
>
>         if (compareAndSetTail(pred, node)) {
>
>             pred.next = node;
>
>             return node;
>
>         }
>
>     }
>
>     enq(node);
>
>     return node;
>
> }
>
> On 01/5/2018 15:30,David Holmes<davidcholmes at aapt.net.au>
> <davidcholmes at aapt.net.au> wrote:
>
> What version of the code are you looking at? I can’t see anything like
> that in current OpenJDK sources.
>
>
>
> David
>
>
>
> *From:* Concurrency-interest [mailto:concurrency-interest-
> bounces at cs.oswego.edu] *On Behalf Of *??? via Concurrency-interest
> *Sent:* Friday, January 5, 2018 4:20 PM
> *To:* concurrency-interest <concurrency-interest at cs.oswego.edu>
> *Subject:* [concurrency-interest] Why "fast path" is faster than full enq
> in AQS
>
>
>
> Hi, everyone:
>
>      I'm reading the source code of "AbstractQueuedSynchronizer", getting
> a little confused of the reason Why "fast path" is faster than full enq in
> the comment "Try the fast path of enq; backup to full enq on failure" .
>
>
> _______________________________________________
> 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/20180106/81f10479/attachment.html>


More information about the Concurrency-interest mailing list