[concurrency-interest] AbstractQueuedSynchronizer

David Holmes davidcholmes at aapt.net.au
Thu Sep 22 17:43:07 EDT 2016

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.




From: Concurrency-interest [mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf Of Martin Buchholz
Sent: Friday, September 23, 2016 12:51 AM
To: Bobrowski, Maciej <Maciej.Bobrowski at morganstanley.com>
Cc: concurrency-interest at cs.oswego.edu; dholmes at ieee.org
Subject: Re: [concurrency-interest] AbstractQueuedSynchronizer




On Thu, Sep 22, 2016 at 5:37 AM, Bobrowski, Maciej <Maciej.Bobrowski at morganstanley.com <mailto:Maciej.Bobrowski at morganstanley.com> > 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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20160923/833e3085/attachment.html>

More information about the Concurrency-interest mailing list