rust_sched_driver race may cause spurious wakeups on Windows

[cpeterso]

I believe rust_sched_driver has a race that may cause spurious (but harmless) wakeups on Windows:

https://github.com/mozilla/rust/blob/12c32e944d3dbadb6a114a6e0bc51b065b4f42c1/src/rt/rust_sched_driver.cpp#L53

Order of events:

1. Assume signal() is called when start_main_loop() is not blocked in lock.wait().
2. signal() will set signalled = true and signal the lock (which calls Windows' SetEvent() API).
3. When start_main_loop() later acquires the lock, signalled is true, so start_main_loop() skips the wait() and resets signalled to false.
4. At this point, signalled is false but the lock's event object is still in the signalled state!
5. When start_main_loop() next acquires the lock, signalled is false, so the function calls wait() which will return immediately because the event is still in the signalled state.

To avoid this problem, start_main_loop() would need to call ResetEvent() in step 3.

[catamorphism]

Not critical for 0.7. Nominating for milestone 5, production-ready.

[graydon]

Declined milestone; spurious wakeups are unfortunate but not blockers.

[catamorphism]

(bug triage) Already declined for milestone, but still open.

[catamorphism]

With the new runtime, this code appears to be no longer. Yay!