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

wen nathanielwen at 163.com
Sun Jan 7 21:35:15 EST 2018


Thank you for your explanation, Martin and David. Thank you very much.

On 01/6/2018 23:39,Martin Buchholz<martinrb at google.com> wrote:
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> 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> 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/20180108/b7fab3c4/attachment.html>


More information about the Concurrency-interest mailing list