Please clarify the behavior of Parker

[lamafab]

Hi

I have some questions about the Parker type. The park() method explicitly mentions the following:

A call to park may wake up spuriously without consuming the token, and callers should be prepared for this possibility.

Questions:

• If I understand this correctly; when a thread blocks at p.park(), it might unblock and continue without having to directly call u.unpark()?
• Under what circumstances can this spurious wake up happen?
• If a certain process requires park() to work reliably, what should be used instead? What's the point of Parker if it's unreliable?

Thanks for your time.

[Lucretiel]

Asked as well on stack overflow: https://stackoverflow.com/questions/63543946/how-are-you-supposed-to-handle-a-spurious-wakeup-of-a-parker/63544651

I'm also confused by this, because my reading of the implementation is that (assuming atomics don't spuriously change value) there shouldn't be any possible spurious wakeups under the current implementation.

[ghost]

It seems spurious wakeups never happen. :)

The reason why the docs mention this is because park() in the standard library has the same disclaimer: https://doc.rust-lang.org/nightly/std/thread/fn.park.html

Note that when we say that wakeups are 'spurious', that means they might happen sometimes but very rarely. In fact, so rarely that you don't need to worry about their performance implications. Usually, parking is done in a while loop and on spurious wakeup we just check whether the loop is done and park again if not. It's kind of similar to how we use compare_exchange_weak instead of compare_exchange in a lot of loops.

I think the original idea behind saying that spurious wakeups are possible is that we might choose to switch to a different, more efficient implementation that does sometimes spuriously unpark, but in my opinion it is unlikely we'll ever change the implementation. So it's just a pessimistic disclaimer that ensures we're not stuck with the current implementation that doesn't spuriously unpark.

Anyways, my opinion is that there's no point in keeping this disclaimer and we should just delete it from the docs.

[Lucretiel]

I have a pull request in progress to deal with this. Spurious wakeups actually are possible with timeout parks, because they never re-check the condition after the condition variable wait finishes. So I'm tying up some of that, and also adding a simple enum that reports whether a park ended due to a timeout or an unpark. I should have that up for review this week.

[Lucretiel]

Note: Once this issue closes, go update the Stack Overflow question and answer as well.