Why "fast path" is faster than full enq in AQS

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Why "fast path" is faster than full enq in AQS

JSR166 Concurrency mailing list
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
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Why "fast path" is faster than full enq in AQS

JSR166 Concurrency mailing list

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:[hidden email]] On Behalf Of ??? via Concurrency-interest
Sent: Friday, January 5, 2018 4:20 PM
To: concurrency-interest <[hidden email]>
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
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Why "fast path" is faster than full enq in AQS

JSR166 Concurrency mailing list
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[hidden email] 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:[hidden email]] On Behalf Of ??? via Concurrency-interest
Sent: Friday, January 5, 2018 4:20 PM
To: concurrency-interest <[hidden email]>
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
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Why "fast path" is faster than full enq in AQS

JSR166 Concurrency mailing list

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:[hidden email]] On Behalf Of ??? via Concurrency-interest
Sent: Friday, January 5, 2018 5:34 PM
To: [hidden email]
Cc: 'Concurrency-interest' <[hidden email]>
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[hidden email] 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:[hidden email]] On Behalf Of ??? via Concurrency-interest
Sent: Friday, January 5, 2018 4:20 PM
To: concurrency-interest <[hidden email]>
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
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Why "fast path" is faster than full enq in AQS

JSR166 Concurrency mailing list
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[hidden email] 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:[hidden email]] On Behalf Of ??? via Concurrency-interest
Sent: Friday, January 5, 2018 5:34 PM
To: [hidden email]
Cc: 'Concurrency-interest' <[hidden email]>
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[hidden email] 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:[hidden email]] On Behalf Of ??? via Concurrency-interest
Sent: Friday, January 5, 2018 4:20 PM
To: concurrency-interest <[hidden email]>
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
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Why "fast path" is faster than full enq in AQS

JSR166 Concurrency mailing list

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:[hidden email]]
Sent: Saturday, January 6, 2018 7:10 PM
To: [hidden email]
Cc: 'Concurrency-interest' <[hidden email]>
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[hidden email] 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:[hidden email]] On Behalf Of ??? via Concurrency-interest
Sent: Friday, January 5, 2018 5:34 PM
To: [hidden email]
Cc: 'Concurrency-interest' <[hidden email]>
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[hidden email] 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:[hidden email]] On Behalf Of ??? via Concurrency-interest
Sent: Friday, January 5, 2018 4:20 PM
To: concurrency-interest <[hidden email]>
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
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Why "fast path" is faster than full enq in AQS

JSR166 Concurrency mailing list
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 <[hidden email]> 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:[hidden email]]
Sent: Saturday, January 6, 2018 7:10 PM


To: [hidden email]
Cc: 'Concurrency-interest' <[hidden email]>
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[hidden email] 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:[hidden email]] On Behalf Of ??? via Concurrency-interest
Sent: Friday, January 5, 2018 5:34 PM
To: [hidden email]
Cc: 'Concurrency-interest' <[hidden email]>
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[hidden email] 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:[hidden email]] On Behalf Of ??? via Concurrency-interest
Sent: Friday, January 5, 2018 4:20 PM
To: concurrency-interest <[hidden email]>
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
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest



_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Why "fast path" is faster than full enq in AQS

JSR166 Concurrency mailing list

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

On 01/6/2018 23:39[hidden email] 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 <[hidden email]> 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:[hidden email]]
Sent: Saturday, January 6, 2018 7:10 PM


To: [hidden email]
Cc: 'Concurrency-interest' <[hidden email]>
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[hidden email] 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:[hidden email]] On Behalf Of ??? via Concurrency-interest
Sent: Friday, January 5, 2018 5:34 PM
To: [hidden email]
Cc: 'Concurrency-interest' <[hidden email]>
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[hidden email] 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:[hidden email]] On Behalf Of ??? via Concurrency-interest
Sent: Friday, January 5, 2018 4:20 PM
To: concurrency-interest <[hidden email]>
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
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest



_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest