AbstractQueuedSynchronizer

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

AbstractQueuedSynchronizer

Bobrowski, Maciej

I have tried to understand the inner working of abstractQueuedSynchronizer and one thing I cannot quite explain.

 

When a thread decides it needs to park itself (let’s say the CountDownLatch counter > 0), it does so by calling LockSuport.park. In the meantime, of course, the latch can be fully counted down, all awaiting threads unparked, while this thread is just about to park itself. Obviously that would not work, as now we have one thread parked, on a latch that is fully counted down, so no good.

 

This does not happen actually (I wrote a small test and verified), and it is down to the code of LockSupport.park()

 

public static void park(Object blocker) {
    Thread t = Thread.currentThread();
    setBlocker(t, blocker);
    unsafe.park(false, 0L);
    setBlocker(t, null);
}

 

Somehow, when the latch is fully counted down and unsafe.park is called, it immediately returns, so there is some magic behind the scenes that tells the thread not to actually park itself. Anyone could cast some light onto what is actually happening?

 

Thanks,

Maciej





NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers  If you cannot access these links, please notify us by reply message and we will send the contents to you. By communicating with Morgan Stanley you consent to the foregoing and to the voice recording of conversations with personnel of Morgan Stanley.


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

Re: AbstractQueuedSynchronizer

David Holmes-6

Park() has a token associated with it, so if unpark() is called before the park() the park() will return immediately and consume the token.

 

David

 

From: Concurrency-interest [mailto:[hidden email]] On Behalf Of Bobrowski, Maciej
Sent: Thursday, September 22, 2016 9:57 PM
To: [hidden email]
Subject: [concurrency-interest] AbstractQueuedSynchronizer

 

I have tried to understand the inner working of abstractQueuedSynchronizer and one thing I cannot quite explain.

 

When a thread decides it needs to park itself (let’s say the CountDownLatch counter > 0), it does so by calling LockSuport.park. In the meantime, of course, the latch can be fully counted down, all awaiting threads unparked, while this thread is just about to park itself. Obviously that would not work, as now we have one thread parked, on a latch that is fully counted down, so no good.

 

This does not happen actually (I wrote a small test and verified), and it is down to the code of LockSupport.park()

 

public static void park(Object blocker) {
    Thread t = Thread.currentThread();
    setBlocker(t, blocker);
    unsafe.park(false, 0L);
    setBlocker(t, null);
}

 

Somehow, when the latch is fully counted down and unsafe.park is called, it immediately returns, so there is some magic behind the scenes that tells the thread not to actually park itself. Anyone could cast some light onto what is actually happening?

 

Thanks,

Maciej

 

 



NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers  If you cannot access these links, please notify us by reply message and we will send the contents to you. By communicating with Morgan Stanley you consent to the foregoing and to the voice recording of conversations with personnel of Morgan Stanley.


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

Re: AbstractQueuedSynchronizer

Bobrowski, Maciej

Thanks. So two questions:

 

1.       What does the set/unset blocker do?

2.       What is the token you are referring to? How does it relate to a latch, which is an entirely different object? In this case, there is no unpark called for that thread as it is not yet part of the wait queue AFAIK

 

From: David Holmes [mailto:[hidden email]]
Sent: 22 September 2016 13:25
To: Bobrowski, Maciej (IST); [hidden email]
Subject: RE: [concurrency-interest] AbstractQueuedSynchronizer

 

Park() has a token associated with it, so if unpark() is called before the park() the park() will return immediately and consume the token.

 

David

 

From: Concurrency-interest [[hidden email]] On Behalf Of Bobrowski, Maciej
Sent: Thursday, September 22, 2016 9:57 PM
To: [hidden email]
Subject: [concurrency-interest] AbstractQueuedSynchronizer

 

I have tried to understand the inner working of abstractQueuedSynchronizer and one thing I cannot quite explain.

 

When a thread decides it needs to park itself (let’s say the CountDownLatch counter > 0), it does so by calling LockSuport.park. In the meantime, of course, the latch can be fully counted down, all awaiting threads unparked, while this thread is just about to park itself. Obviously that would not work, as now we have one thread parked, on a latch that is fully counted down, so no good.

 

This does not happen actually (I wrote a small test and verified), and it is down to the code of LockSupport.park()

 

public static void park(Object blocker) {
    Thread t = Thread.currentThread();
    setBlocker(t, blocker);
    unsafe.park(false, 0L);
    setBlocker(t, null);
}

 

Somehow, when the latch is fully counted down and unsafe.park is called, it immediately returns, so there is some magic behind the scenes that tells the thread not to actually park itself. Anyone could cast some light onto what is actually happening?

 

Thanks,

Maciej

 

 



NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers  If you cannot access these links, please notify us by reply message and we will send the contents to you. By communicating with Morgan Stanley you consent to the foregoing and to the voice recording of conversations with personnel of Morgan Stanley.





NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers  If you cannot access these links, please notify us by reply message and we will send the contents to you. By communicating with Morgan Stanley you consent to the foregoing and to the voice recording of conversations with personnel of Morgan Stanley.


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

Re: AbstractQueuedSynchronizer

Martin Buchholz-3


On Thu, Sep 22, 2016 at 5:37 AM, Bobrowski, Maciej <[hidden email]> wrote:

Thanks. So two questions:

 

1.       What does the set/unset blocker do?

Just for monitoring (identifying lock owner in stack traces), not concurrency control.

2.       What is the token you are referring to? How does it relate to a latch, which is an entirely different object? In this case, there is no unpark called for that thread as it is not yet part of the wait queue AFAIK

When a thread can't make progress, it publishes a request to unpark in some shared data structure, then parks.  If the unpark racily arrives before the park, the park returns immediately.


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

Re: AbstractQueuedSynchronizer

David Holmes-6

Just to add on to #2. The token is part of the park/unpark implementation – as described in its Javadoc.

 

There is an inherent race between a thread enqueuing itself to await for a condition, releasing all associated “locks” and calling park() to actually suspend itself. If the condition changes before the park() occurs we need to ensure that the park() will return as soon as it is actually called, and unpark() achieves that by setting the token. So the thread that is changing the state of the AQS sees that a thread is queued, unqueues it and unpark()s the thread.

 

David

 

From: Concurrency-interest [mailto:[hidden email]] On Behalf Of Martin Buchholz
Sent: Friday, September 23, 2016 12:51 AM
To: Bobrowski, Maciej <[hidden email]>
Cc: [hidden email]; [hidden email]
Subject: Re: [concurrency-interest] AbstractQueuedSynchronizer

 

 

 

On Thu, Sep 22, 2016 at 5:37 AM, Bobrowski, Maciej <[hidden email]> wrote:

Thanks. So two questions:

 

1.       What does the set/unset blocker do?

Just for monitoring (identifying lock owner in stack traces), not concurrency control.

2.       What is the token you are referring to? How does it relate to a latch, which is an entirely different object? In this case, there is no unpark called for that thread as it is not yet part of the wait queue AFAIK

When a thread can't make progress, it publishes a request to unpark in some shared data structure, then parks.  If the unpark racily arrives before the park, the park returns immediately.

 


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