FIFO and LIFO strategies

[ghost]

This PR adds two different ordering strategies to the deque: FIFO and LIFO. The strategy is chosen at construction time. There are two deque constructors:

fn fifo<T>() -> (Worker<T>, Stealer<T>);
fn lifo<T>() -> (Worker<T>, Stealer<T>);

FIFO is intended to be used by Tokio and LIFO is for Rayon. The FIFO variant doesn't execute any fences.

I've tried running benchmarks on Rayon's test suite and didn't find any significant differences between this PR and the current master branch.

The LIFO variant is the same as our current Chase-Lev implementation, while FIFO is slightly tweaked CircBuf. I've fixed a few bugs in CircBuf, cleaned up the code, and conservatively added a bit stronger memory orderings where I found them dubious. This time correctness is the primary concern, but we can revisit those orderings later to squeeze out more performance.

In a future PR we can also add methods for batched stealing (steal half), as explained in #11.

Another thing we should consider adding later is workers that can be shared among multiple threads. In addition to thread-local deques, schedulers usually also have a special global deque, where tasks without an associated worker thread go into (rayon::spawn pushes tasks into the global deque). Rayon currently uses Mutex<Worker<T>> and Stealer<T> for the global deque. The mutex around Worker<T> is unfortunate so we should ideally add a variant of deque that supports push and pop from multiple threads without mutexes. Such a deque would probably be implemented as a Treiber stack when using LIFO strategy and as a Michael-Scott queue when using FIFO strategy.

Closes #11
cc @carllerche

[ghost]

What do you think, @jeehoonkang? :)

I don't think this PR needs thorough review - it's just refactoring + CircBuf with slightly stronger orderings (for now).

[ghost]

As suggested in tokio-rs/tokio#426, I've moved some worker-specific data from Inner into Worker. This means buffer pointer, buffer capacity, and the back index get inlined directly into worker::Entry.

Comparison between the Tokio master branch and my local branch that uses this PR:

 name                    before ns/iter  after ns/iter  diff ns/iter  diff %  speedup
 threadpool::spawn_many  4,659,536       4,199,011          -460,525  -9.88%   x 1.11
 threadpool::yield_many  11,949,901      12,170,009          220,108   1.84%   x 0.98

The yield_many benchmark is slightly slower now - my guess is that's because the steal operation is now a bit slower in case the deque is empty (because we have to load the stamp inside the buffer instead of loading the back index). But I believe this is overall for the better.

I'm also hopeful that batched stealing will give us further performance wins.

(Just a reminder: this is blocked on Tokio upgrading to Rust 1.25).

[carllerche]

I merged tokio-rs/tokio#465, so Tokio should be on 1.25

[ghost]

Ok, let's merge this.

@jeehoonkang I'm going to skip the review - if you have any comments on this PR, let me know anytime. :)