sync ops for queue

[conradludgate]

I was looking to see if I could replace the Mutex<VecDeque<T>> from the deadpool crate, but there's an interesting requirement here - deadpool has a resize method that can resize the queue.

Not to be deterred, I am hoping to use a RwLock<ArrayQueue<T>>. 99% of ops will call slots.read().pop(), but for the resize function, I was intending to use slots.write() to get sole ownership, then I could mem::swap in a new queue. This would be fine, but I thought it could be more efficient.

This PR introduces an efficient implementation of some of the sync (&mut self) operations for inserting into the queue, as well as that resize method.

pop_sync,push_sync,force_push_sync are much like their shared counterparts, except they don't need to care about atomic load orderings. (I'm open to alternative namings)

resize is a little more complicated:

1. We 'reset' the queue. This shifts all live slots to the front of the slice
2. We take out the buffer from the queue as a vec - leaving a dangling empty box in it's place
3. We either reserve and fill, or truncate and shrink our vec
4. We turn our vec back into a boxed slice, and update our queue to match

[conradludgate]

Developing for older MSRVs on an M1 mac is hard 🙃 the minimum rust I can install is 1.49

[taiki-e]

Developing for older MSRVs on an M1 mac is hard 🙃 the minimum rust I can install is 1.49

FYI, you can use rustup toolchain add 1.38-x86_64-apple-darwin and cargo +1.38-x86_64-apple-darwin build.

[conradludgate]

Developing for older MSRVs on an M1 mac is hard 🙃 the minimum rust I can install is 1.49

FYI, you can use rustup toolchain add 1.38-x86_64-apple-darwin and cargo +1.38-x86_64-apple-darwin build.

Thanks, it seems to build locally now 😅

[conradludgate]

Ok - I'm in no rush for this to get reviewed. Having swapped out the deadpool queue for this impl, I get noticeable regressions for some reason :(

[taiki-e]

Ok, marked this as draft for now.