On the specification of park()

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

On the specification of park()

Andrew Haley
The spec says

> The park method may also return at any other time, for "no reason",

Looking at the OpenJDK implementation, I don't think it will do that.
What is the reason park() is specified this way?

Andrew.


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

Re: On the specification of park()

Jason Tedor
I think this is due to the notion of spurious wakeups (https://en.wikipedia.org/wiki/Spurious_wakeup).

On Sat, Sep 24, 2016 at 11:51 AM Andrew Haley <[hidden email]> wrote:
The spec says

> The park method may also return at any other time, for "no reason",

Looking at the OpenJDK implementation, I don't think it will do that.
What is the reason park() is specified this way?

Andrew.


_______________________________________________
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: On the specification of park()

Doug Lea
In reply to this post by Andrew Haley
On 09/24/2016 11:47 AM, Andrew Haley wrote:
> The spec says
>
>> The park method may also return at any other time, for "no reason",
>
> Looking at the OpenJDK implementation, I don't think it will do that.
> What is the reason park() is specified this way?
>

There's a lot of mythology and controversy about this
(as the first bunch of google hits will point you to), but the
main reason is that when finite resources (hardware or memory) are
used to implement blocking for a series of conditions, there can
be races in which a signal for the previous usage cannot be
distinguished from a signal to the new usage, so a wakeup occurs
to be safe. This is usually the case for example when using
immortal typed memory pools, which is (or at least was) the case
for hotspot's thread.parker field.

-Doug

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