Implement async_std::sync::Condvar

[tmccombs]

Part of #217

[nbdd0121]

@nbdd0121 do you have any suggestion on how to resolve your concerns?

I think notifying another waker when a WaitFuture is dropped with its opt_waker set to None should be enough. This should handle the notify_one well, but it may cause extra tasks being notified if we
have the following case:

• Task A calls wait
• Task B calls notify_all
• Task C calls wait
• Task A cancels wait

Task C will ends up being waken up. However I don't think it's a huge problem, because std's Condvar mentions that:

Note that this function is susceptible to spurious wakeups. Condition variables normally have a boolean predicate associated with them, and the predicate must always be checked each time this function returns to protect against spurious wakeups.

[nbdd0121]

IMO we don't need has_blocked. Unlike Mutex which assumes most calls don't block, for Condvar I think we can assume there are tasks blocking when notify_one or notify_all is called.

[roblabla]

I feel like the wait/wait_timeout are kinda big footguns. If I understand them properly, the returned future will always return Ready the second time they're polled, without necessarily being actually notified. This can happen quite easily by using e.g. the join adapter from futures-rs.

This is technically okay according to Condvars' spurious wakeup conditions, but that is not mentioned at all in the docs. Besides, it seems very trivial to cause a spurious wakeups here compared to on a "normal" blocking implementation, and will likely produce bad, hard to debug code. I kinda question the usefulness of those functions compared to wait_until.

[tmccombs]

If I understand them properly, the returned future will always return Ready the second time they're polled

Kind of. They will return Ready if they are polled and the attached Mutex is available. I could potentially use an Arc<AtomicBool> to keep track of if it was actually notified. But I think (though I don't have benchmarks) that in most cases that would hurt performance.

[nbdd0121]

Kind of. They will return Ready if they are polled and the attached Mutex is available. I could potentially use an Arc<AtomicBool> to keep track of if it was actually notified. But I think (though I don't have benchmarks) that in most cases that would hurt performance.

Probably only need to check if Option<Waker> is turned to None. Otherwise it'll be spurious wake up.

[tmccombs]

Probably only need to check if Option is turned to None. Otherwise it'll be spurious wake up.

Yes, but that requires locking the mutex for the wakers when polled, which is doable, but could hurt performance if the condition variable has very much contention. And if wait_until/wait_timeout_until are used, then it isn't an issue.

[nbdd0121]

You need to lock the mutex to remove the waker when cancelling/completing the notify call, or to insert the waker when beginning a new call. I don't see why it'll hurt performance compared to wait_until.

[tmccombs]

Ok, I'll take a stab at implementing that. It looks like there is also now a WakerSet type that I should use instead of a Slab of Wakers.

[tmccombs]

@nbdd0121 I think my latest push should address your concerns.

[nbdd0121]

WakerSet's notify_one does not wake up anything if some task is woken already. This is slightly different from Condvar's notify_one which should always wake up one task (in the case of two concurrent notify_one call for example).

[tmccombs]

If i understand the code on master that is how notify_any behaves, but notify_one behaves as we want for condvar.

[nbdd0121]

Sorry, you're right. That change is introduced in e9edadf which isn't part of a PR so I am not aware of.

[dignifiedquire]

what about this comment?

[dignifiedquire]

Some small things and needs a rebase, but other than that I think this looks good and we should really get this in, it is quite a useful primitive

[tmccombs]

I rebased and addressed your comments. Should I squash as well?

[dignifiedquire]

Thank you