Could park/unpark be changed to directly accommodate messages?

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

Could park/unpark be changed to directly accommodate messages?

thurstonn
Here's what I had in mind:


unpark(Thread, Object message)

Object   park()


Of course I realize that there are many different ways to indirectly accomplish the same thing presently (which is part of the problem).  But isn't this the kind of thing that could be optimized for each platform, using whatever intrinsics are natively available (not to mention standardizing a "best approach" for developers)?

This would in effect, just be adding asynchronous messaging to Java, but is that a bad thing?
I'm sure this isn't the first time that such a thing has been suggested, and I'm just curious as to what the practical difficulties (spurious "deparks" are clearly one problem, platform differences are surely another) are that have prevented its adoption.  I've never seen a discussion directly addressing the topic, so I thought I would try it here.

Thanks
Reply | Threaded
Open this post in threaded view
|

Re: Could park/unpark be changed to directly accommodate messages?

Andrew Haley
On 08/06/16 13:42, thurstonn wrote:
> Of course I realize that there are many different ways to indirectly
> accomplish the same thing presently (which is part of the problem).  But
> isn't this the kind of thing that could be optimized for each platform,
> using whatever intrinsics are natively available (not to mention
> standardizing a "best approach" for developers)?

park() is the lowest-level possible primitive.  It may be implemented
with very simple code: just a few instructions.  Of course a
message-passing layer can be put on top of park(), but then it
wouldn't be park(), it would be a blocking send and receive.

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

Re: Could park/unpark be changed to directly accommodate messages?

thurstonn
Andrew Haley wrote
On 08/06/16 13:42, thurstonn wrote:
> Of course I realize that there are many different ways to indirectly
> accomplish the same thing presently (which is part of the problem).  But
> isn't this the kind of thing that could be optimized for each platform,
> using whatever intrinsics are natively available (not to mention
> standardizing a "best approach" for developers)?

park() is the lowest-level possible primitive.  It may be implemented
with very simple code: just a few instructions.  Of course a
message-passing layer can be put on top of park(), but then it
wouldn't be park(), it would be a blocking send and receive.

Andrew.
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Fair enough, I guess what I'm really asking is isn't it possible to implement platform-specific send and receive (I'm not talking about a Java language facade - obviously those can and have been done), then.
And what are the practical difficulties in doing so?
Reply | Threaded
Open this post in threaded view
|

Re: Could park/unpark be changed to directly accommodate messages?

Alex Otenko
In reply to this post by thurstonn
No.

park() inherently can wake up spuriously. It is up to the designer of the concurrent algorithm to determine whether the wake up was spurious or intended.

Since you are going to solve that problem anyway, you may just as well pass the object at the same time.

Alex

> On 8 Jun 2016, at 13:42, thurstonn <[hidden email]> wrote:
>
> Here's what I had in mind:
>
>
> unpark(Thread, Object message)
>
> Object   park()
>
>
> Of course I realize that there are many different ways to indirectly
> accomplish the same thing presently (which is part of the problem).  But
> isn't this the kind of thing that could be optimized for each platform,
> using whatever intrinsics are natively available (not to mention
> standardizing a "best approach" for developers)?
>
> This would in effect, just be adding asynchronous messaging to Java, but is
> that a bad thing?
> I'm sure this isn't the first time that such a thing has been suggested, and
> I'm just curious as to what the practical difficulties (spurious "deparks"
> are clearly one problem, platform differences are surely another) are that
> have prevented its adoption.  I've never seen a discussion directly
> addressing the topic, so I thought I would try it here.
>
> Thanks
>
>
>
>
> --
> View this message in context: http://jsr166-concurrency.10961.n7.nabble.com/Could-park-unpark-be-changed-to-directly-accommodate-messages-tp13531.html
> Sent from the JSR166 Concurrency mailing list archive at Nabble.com.
> _______________________________________________
> 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: Could park/unpark be changed to directly accommodate messages?

Andrew Haley
In reply to this post by thurstonn
On 08/06/16 14:25, thurstonn wrote:
> Fair enough, I guess what I'm really asking is isn't it possible to
> implement platform-specific send and receive (I'm not talking about a Java
> language facade - obviously those can and have been done), then.
> And what are the practical difficulties in doing so?

There are no practical difficulties as far as I'm aware.  A simple JNI
version could be done in an afternoon.  A C2 intrinsic would take a
while longer.

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

Re: Could park/unpark be changed to directly accommodate messages?

Chris Vest
In reply to this post by thurstonn
You can store the message in a field on unpark(), then read and clear the field upon returning from park().
That would be the behaviour as far as I can see, except the field wouldn’t necessarily be in the Thread object - you can put it in an object with a bit more context of use, though that creates the problem that the field is now potentially shared across multiple threads.
Meanwhile park() can return in response to zero (spurious) or many unparks, and the reads of the field can race with yet more calls to unpark, so the field access will be racy and prone to lost updates in any case.
The park() and unpark() methods are also used by many different components, which is one of the sources of spurious wake-ups; unparks intended for one park call that ends up waking up a completely different park call in a different (or same) concurrency primitive.

I don’t see it as a problem that there are many different ways to pass information between threads. Different situations demand different properties of the concurrency primitives. We can choose and make trade-offs between properties of delivery, performance and safety guarantees.
Off the top of my head I don’t know of a primitive with such weak safety properties as what I outlined above, so maybe there isn’t very much need for such a thing. That would be my guess, assuming I’ve understood what you are asking.

At one point I had use for, and created, a sort of one-way single-use exchanger (a Promise of sorts) where one thread could wait for a value to appear, and another could with a single method set a field in this exchanger, and unpark the waiting thread. But this still did looping to account for spurious wake-ups, and they were single-use so I could check the field for null to determine if a value had arrived or not. So not quite general asynchronous messaging, and not a use case that would be solved by your API even though it at first glance might look like a good fit.

Cheers,
Chris

On 08 Jun 2016, at 14:42, thurstonn <[hidden email]> wrote:

Here's what I had in mind:


unpark(Thread, Object message)

Object   park()


Of course I realize that there are many different ways to indirectly
accomplish the same thing presently (which is part of the problem).  But
isn't this the kind of thing that could be optimized for each platform,
using whatever intrinsics are natively available (not to mention
standardizing a "best approach" for developers)?

This would in effect, just be adding asynchronous messaging to Java, but is
that a bad thing?
I'm sure this isn't the first time that such a thing has been suggested, and
I'm just curious as to what the practical difficulties (spurious "deparks"
are clearly one problem, platform differences are surely another) are that
have prevented its adoption.  I've never seen a discussion directly
addressing the topic, so I thought I would try it here.

Thanks




--
View this message in context: http://jsr166-concurrency.10961.n7.nabble.com/Could-park-unpark-be-changed-to-directly-accommodate-messages-tp13531.html
Sent from the JSR166 Concurrency mailing list archive at Nabble.com.
_______________________________________________
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: Could park/unpark be changed to directly accommodate messages?

Nathan and Ila Reynolds

If I understand correctly, some environments really can cause the thread to return from park() without a call to unpark().  This is a spurious return of park().

 

There is another source of “spurious” returns of park().  With so many concurrency constructs throughout a large project, there will be times when Thread A calls unpark() on Thread B and Thread B has long since left the associated code and is executing in some other area of the large project.  In fact, Thread B could be parked somewhere else and become unparked needlessly.

 

The same can happen with Thread.interrupt().  I have actually seen this case.  A thread called into some library and then came out of the library.  The thread then called Object.wait() on an unrelated object only to be erroneously interrupted by another thread in the library.

 

My point is that one has to always handle “spurious” returns of park().  park() should almost always be put in a loop.  When the thread wakes up from park(), it should check the condition inside the loop and then either exit the loop or go back to park().

 

Since the thread is almost always in a park() loop, one can easily pass a message to the thread which wakes up.  In fact, couldn’t one use an Exchanger to pass messages?

 

-Nathan

 

From: Concurrency-interest [mailto:[hidden email]] On Behalf Of Chris Vest
Sent: Wednesday, June 08, 2016 8:51 AM
To: thurstonn <[hidden email]>
Cc: [hidden email]
Subject: Re: [concurrency-interest] Could park/unpark be changed to directly accommodate messages?

 

You can store the message in a field on unpark(), then read and clear the field upon returning from park().

That would be the behaviour as far as I can see, except the field wouldn’t necessarily be in the Thread object - you can put it in an object with a bit more context of use, though that creates the problem that the field is now potentially shared across multiple threads.

Meanwhile park() can return in response to zero (spurious) or many unparks, and the reads of the field can race with yet more calls to unpark, so the field access will be racy and prone to lost updates in any case.

The park() and unpark() methods are also used by many different components, which is one of the sources of spurious wake-ups; unparks intended for one park call that ends up waking up a completely different park call in a different (or same) concurrency primitive.

 

I don’t see it as a problem that there are many different ways to pass information between threads. Different situations demand different properties of the concurrency primitives. We can choose and make trade-offs between properties of delivery, performance and safety guarantees.

Off the top of my head I don’t know of a primitive with such weak safety properties as what I outlined above, so maybe there isn’t very much need for such a thing. That would be my guess, assuming I’ve understood what you are asking.

 

At one point I had use for, and created, a sort of one-way single-use exchanger (a Promise of sorts) where one thread could wait for a value to appear, and another could with a single method set a field in this exchanger, and unpark the waiting thread. But this still did looping to account for spurious wake-ups, and they were single-use so I could check the field for null to determine if a value had arrived or not. So not quite general asynchronous messaging, and not a use case that would be solved by your API even though it at first glance might look like a good fit.


Cheers,

Chris

 

On 08 Jun 2016, at 14:42, thurstonn <[hidden email]> wrote:

 

Here's what I had in mind:


unpark(Thread, Object message)

Object   park()


Of course I realize that there are many different ways to indirectly
accomplish the same thing presently (which is part of the problem).  But
isn't this the kind of thing that could be optimized for each platform,
using whatever intrinsics are natively available (not to mention
standardizing a "best approach" for developers)?

This would in effect, just be adding asynchronous messaging to Java, but is
that a bad thing?
I'm sure this isn't the first time that such a thing has been suggested, and
I'm just curious as to what the practical difficulties (spurious "deparks"
are clearly one problem, platform differences are surely another) are that
have prevented its adoption.  I've never seen a discussion directly
addressing the topic, so I thought I would try it here.

Thanks




--
View this message in context: http://jsr166-concurrency.10961.n7.nabble.com/Could-park-unpark-be-changed-to-directly-accommodate-messages-tp13531.html
Sent from the JSR166 Concurrency mailing list archive at Nabble.com.
_______________________________________________
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: Could park/unpark be changed to directly accommodate messages?

David M. Lloyd-3
This seems closely related to the occasionally-mentioned idea of parking
relative to a change to a particular memory location, which might be the
better primitive choice since it could probably be used to implement
message passing (among other things).  I'm not sure that what we have
for VarHandle support is sufficient to accomplish this though.

On 06/08/2016 11:18 AM, Nathan & Ila Reynolds wrote:

> If I understand correctly, some environments really can cause the thread
> to return from park() without a call to unpark().  This is a spurious
> return of park().
>
> There is another source of “spurious” returns of park().  With so many
> concurrency constructs throughout a large project, there will be times
> when Thread A calls unpark() on Thread B and Thread B has long since
> left the associated code and is executing in some other area of the
> large project.  In fact, Thread B could be parked somewhere else and
> become unparked needlessly.
>
> The same can happen with Thread.interrupt().  I have actually seen this
> case.  A thread called into some library and then came out of the
> library.  The thread then called Object.wait() on an unrelated object
> only to be erroneously interrupted by another thread in the library.
>
> My point is that one has to always handle “spurious” returns of park().
> park() should almost always be put in a loop.  When the thread wakes up
> from park(), it should check the condition inside the loop and then
> either exit the loop or go back to park().
>
> Since the thread is almost always in a park() loop, one can easily pass
> a message to the thread which wakes up.  In fact, couldn’t one use an
> Exchanger to pass messages?
>
> -Nathan
>
> *From:*Concurrency-interest
> [mailto:[hidden email]] *On Behalf Of *Chris
> Vest
> *Sent:* Wednesday, June 08, 2016 8:51 AM
> *To:* thurstonn <[hidden email]>
> *Cc:* [hidden email]
> *Subject:* Re: [concurrency-interest] Could park/unpark be changed to
> directly accommodate messages?
>
> You can store the message in a field on unpark(), then read and clear
> the field upon returning from park().
>
> That would be the behaviour as far as I can see, except the field
> wouldn’t necessarily be in the Thread object - you can put it in an
> object with a bit more context of use, though that creates the problem
> that the field is now potentially shared across multiple threads.
>
> Meanwhile park() can return in response to zero (spurious) or many
> unparks, and the reads of the field can race with yet more calls to
> unpark, so the field access will be racy and prone to lost updates in
> any case.
>
> The park() and unpark() methods are also used by many different
> components, which is one of the sources of spurious wake-ups; unparks
> intended for one park call that ends up waking up a completely different
> park call in a different (or same) concurrency primitive.
>
> I don’t see it as a problem that there are many different ways to pass
> information between threads. Different situations demand different
> properties of the concurrency primitives. We can choose and make
> trade-offs between properties of delivery, performance and safety
> guarantees.
>
> Off the top of my head I don’t know of a primitive with such weak safety
> properties as what I outlined above, so maybe there isn’t very much need
> for such a thing. That would be my guess, assuming I’ve understood what
> you are asking.
>
> At one point I had use for, and created, a sort of one-way single-use
> exchanger (a Promise of sorts) where one thread could wait for a value
> to appear, and another could with a single method set a field in this
> exchanger, and unpark the waiting thread. But this still did looping to
> account for spurious wake-ups, and they were single-use so I could check
> the field for null to determine if a value had arrived or not. So not
> quite general asynchronous messaging, and not a use case that would be
> solved by your API even though it at first glance might look like a good
> fit.
>
>
> Cheers,
>
> Chris
>
>     On 08 Jun 2016, at 14:42, thurstonn <[hidden email]
>     <mailto:[hidden email]>> wrote:
>
>     Here's what I had in mind:
>
>
>     unpark(Thread, Object message)
>
>     Object   park()
>
>
>     Of course I realize that there are many different ways to indirectly
>     accomplish the same thing presently (which is part of the problem).  But
>     isn't this the kind of thing that could be optimized for each platform,
>     using whatever intrinsics are natively available (not to mention
>     standardizing a "best approach" for developers)?
>
>     This would in effect, just be adding asynchronous messaging to Java,
>     but is
>     that a bad thing?
>     I'm sure this isn't the first time that such a thing has been
>     suggested, and
>     I'm just curious as to what the practical difficulties (spurious
>     "deparks"
>     are clearly one problem, platform differences are surely another)
>     are that
>     have prevented its adoption.  I've never seen a discussion directly
>     addressing the topic, so I thought I would try it here.
>
>     Thanks
>
>
>
>
>     --
>     View this message in context:
>     http://jsr166-concurrency.10961.n7.nabble.com/Could-park-unpark-be-changed-to-directly-accommodate-messages-tp13531.html
>     Sent from the JSR166 Concurrency mailing list archive at Nabble.com
>     <http://nabble.com>.
>     _______________________________________________
>     Concurrency-interest mailing list
>     [hidden email]
>     <mailto:[hidden email]>
>     http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>

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

Re: Could park/unpark be changed to directly accommodate messages?

thurstonn
Similar, but not quite the same; because in your posit, you'd need to define the semantics of multiple threads parking on the same memory address (which one of those threads gets "deparked"? it's very similar to notify()/wait() in that respect)

It's often desirable that a program can select which thread it wants to communicate with, using whatever program-specific criteria it needs (e.g. thread waiting longest)

David M. Lloyd-3 wrote
This seems closely related to the occasionally-mentioned idea of parking
relative to a change to a particular memory location, which might be the
better primitive choice since it could probably be used to implement
message passing (among other things).  I'm not sure that what we have
for VarHandle support is sufficient to accomplish this though.

On 06/08/2016 11:18 AM, Nathan & Ila Reynolds wrote:
> If I understand correctly, some environments really can cause the thread
> to return from park() without a call to unpark().  This is a spurious
> return of park().
>
> There is another source of “spurious” returns of park().  With so many
> concurrency constructs throughout a large project, there will be times
> when Thread A calls unpark() on Thread B and Thread B has long since
> left the associated code and is executing in some other area of the
> large project.  In fact, Thread B could be parked somewhere else and
> become unparked needlessly.
>
> The same can happen with Thread.interrupt().  I have actually seen this
> case.  A thread called into some library and then came out of the
> library.  The thread then called Object.wait() on an unrelated object
> only to be erroneously interrupted by another thread in the library.
>
> My point is that one has to always handle “spurious” returns of park().
> park() should almost always be put in a loop.  When the thread wakes up
> from park(), it should check the condition inside the loop and then
> either exit the loop or go back to park().
>
> Since the thread is almost always in a park() loop, one can easily pass
> a message to the thread which wakes up.  In fact, couldn’t one use an
> Exchanger to pass messages?
>
> -Nathan
>
> *From:*Concurrency-interest
> [mailto:[hidden email]] *On Behalf Of *Chris
> Vest
> *Sent:* Wednesday, June 08, 2016 8:51 AM
> *To:* thurstonn <[hidden email]>
> *Cc:* [hidden email]
> *Subject:* Re: [concurrency-interest] Could park/unpark be changed to
> directly accommodate messages?
>
> You can store the message in a field on unpark(), then read and clear
> the field upon returning from park().
>
> That would be the behaviour as far as I can see, except the field
> wouldn’t necessarily be in the Thread object - you can put it in an
> object with a bit more context of use, though that creates the problem
> that the field is now potentially shared across multiple threads.
>
> Meanwhile park() can return in response to zero (spurious) or many
> unparks, and the reads of the field can race with yet more calls to
> unpark, so the field access will be racy and prone to lost updates in
> any case.
>
> The park() and unpark() methods are also used by many different
> components, which is one of the sources of spurious wake-ups; unparks
> intended for one park call that ends up waking up a completely different
> park call in a different (or same) concurrency primitive.
>
> I don’t see it as a problem that there are many different ways to pass
> information between threads. Different situations demand different
> properties of the concurrency primitives. We can choose and make
> trade-offs between properties of delivery, performance and safety
> guarantees.
>
> Off the top of my head I don’t know of a primitive with such weak safety
> properties as what I outlined above, so maybe there isn’t very much need
> for such a thing. That would be my guess, assuming I’ve understood what
> you are asking.
>
> At one point I had use for, and created, a sort of one-way single-use
> exchanger (a Promise of sorts) where one thread could wait for a value
> to appear, and another could with a single method set a field in this
> exchanger, and unpark the waiting thread. But this still did looping to
> account for spurious wake-ups, and they were single-use so I could check
> the field for null to determine if a value had arrived or not. So not
> quite general asynchronous messaging, and not a use case that would be
> solved by your API even though it at first glance might look like a good
> fit.
>
>
> Cheers,
>
> Chris
>
>     On 08 Jun 2016, at 14:42, thurstonn <[hidden email]
>     <mailto:[hidden email]>> wrote:
>
>     Here's what I had in mind:
>
>
>     unpark(Thread, Object message)
>
>     Object   park()
>
>
>     Of course I realize that there are many different ways to indirectly
>     accomplish the same thing presently (which is part of the problem).  But
>     isn't this the kind of thing that could be optimized for each platform,
>     using whatever intrinsics are natively available (not to mention
>     standardizing a "best approach" for developers)?
>
>     This would in effect, just be adding asynchronous messaging to Java,
>     but is
>     that a bad thing?
>     I'm sure this isn't the first time that such a thing has been
>     suggested, and
>     I'm just curious as to what the practical difficulties (spurious
>     "deparks"
>     are clearly one problem, platform differences are surely another)
>     are that
>     have prevented its adoption.  I've never seen a discussion directly
>     addressing the topic, so I thought I would try it here.
>
>     Thanks
>
>
>
>
>     --
>     View this message in context:
>     http://jsr166-concurrency.10961.n7.nabble.com/Could-park-unpark-be-changed-to-directly-accommodate-messages-tp13531.html
>     Sent from the JSR166 Concurrency mailing list archive at Nabble.com
>     <http://nabble.com>.
>     _______________________________________________
>     Concurrency-interest mailing list
>     [hidden email]
>     <mailto:[hidden email]>
>     http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>

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