Example CondVar code should explicitly drop the MutexGuard after it's done with it

[dfoxfranke]

At the very end of

rust/src/libstd/sync/condvar.rs

Lines 89 to 110 in 6b561b4

	/// use std::sync::{Arc, Mutex, Condvar};
	/// use std::thread;
	///
	/// let pair = Arc::new((Mutex::new(false), Condvar::new()));
	/// let pair2 = pair.clone();
	///
	/// // Inside of our lock, spawn a new thread, and then wait for it to start.
	/// thread::spawn(move|| {
	/// let (lock, cvar) = &*pair2;
	/// let mut started = lock.lock().unwrap();
	/// *started = true;
	/// // We notify the condvar that the value has changed.
	/// cvar.notify_one();
	/// });
	///
	/// // Wait for the thread to start up.
	/// let (lock, cvar) = &*pair;
	/// let mut started = lock.lock().unwrap();
	/// while !*started {
	/// started = cvar.wait(started).unwrap();
	/// }
	/// ```

and in all similar examples elsewhere in the file, there should be a std::mem::drop(started) call. Leaving a condition variable's mutex held after we're no longer watching it will block and possibly deadlock notifier threads.

[dfoxfranke]

Real-world example where this bit me: in the main thread of my program, I was waiting on a condition variable and then calling runtime.shutdown_now().wait().unwrap(), with runtime being a tokio runtime. The condition variable was set by a SIGTERM signal handler. Worked fine, unless the program got two back-to-back signals without the main thread waking up in between. In that case, the second instance of the signal handler would block on the mutex, which would never get released because the main thread was in turn blocked inside wait() waiting for the signal handler future's poll() method to return.