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

温昊祥 nathanielwen at 163.com
Fri Jan 5 02:34:17 EST 2018


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" .
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20180105/9949045b/attachment.html>


More information about the Concurrency-interest mailing list