* upgrade to rand 0.7.0 (MSRV 1.32)
* upgrade to parking_lot 0.9.0
* Remove last non-dev dependency on rand crate (#1324)
Use std RandomState for XorShift seeding. This allows dropping _rand_
crate dep here, accept as a dev dependency for tests or benchmarks.
* increase CI MSRV to 1.31.0
* increase nightly for CI TSAN tests
* add TSAN suppressions for recent rand related updates
* make latest TSAN suppression patterns more general
* upgrade tempfile dev dep for common rand version
But avoid tempfile 3.2 for now, since history demonstrates it bumps
rand versions and MSRV in MINOR updates.
* update (dev dep) env_logger to latest 0.6
* reactor, threadpool: bump PATCH versions, doc links, change logs [ci-release]
This PR introduces `Lock`: A concurrency primitive built on top of `Semaphore` that provides a `Mutex`-like primitive that interacts nicely with futures. Specifically, `LockGuard` (in contrast to `MutexGuard`) does _not_ borrow the `Lock`, and can thus be passed into a future where it will later be unlocked.
This replaces #958, which attempted to introduce a less generic version. The primitive proposed there will instead live in [`async-lease`](https://github.com/jonhoo/async-lease).
A single-producer, multi-consumer channel that only retains the _last_ sent
value. Values are broadcasted out.
This channel is useful for watching for changes to a value from multiple
points in the code base (for example, changes to a configuration value).
Introduce a tokio-sync crate containing useful synchronization primitives for programs
written using Tokio.
The initial release contains:
* An mpsc channel
* A oneshot channel
* A semaphore implementation
* An `AtomicTask` primitive.
The `oneshot` and `mpsc` channels are new implementations providing improved
performance characteristics. In some benchmarks, the new mpsc channel shows
up to 7x improvement over the version provided by the `futures` crate. Unfortunately,
the `oneshot` implementation only provides a slight performance improvement as it
is mostly limited by the `futures` 0.1 task system. Once updated to the `std` version
of `Future` (currently nightly only), much greater performance improvements should
be achievable by `oneshot`.
Additionally, he implementations provided here are checked using
[Loom](http://github.com/carllerche/loom/), which provides greater confidence of
correctness.
Lucio Franco