Implement pool for any 32/64-bit architecture that supports the corresponding atomics.

[reitermarkus]

Closes #421.

[Dirbaio]

do we know why the current code is impl'd only for x86? It could be because the treiber stack is only sound in x86 thanks to its stronger ordering guarantees. Or it could be because cfg(target_has_atomic) didn't exist back then and the original author thought "meh x86 is the only major 32bit arch with 64bit atomics so let's just hardcode it".

Would be good to know before we lift the restriction. I'm not familiar at all with these fancier atomics stuff.

[jamesmunns]

do we know why the current code is impl'd only for x86? It could be because the treiber stack is only sound in x86 thanks to its stronger ordering guarantees. Or it could be because cfg(target_has_atomic) didn't exist back then and the original author thought "meh x86 is the only major 32bit arch with 64bit atomics so let's just hardcode it".

Would be good to know before we lift the restriction. I'm not familiar at all with these fancier atomics stuff.

I think the trick here is that the trieber stack is susceptible to the ABA problem: https://en.wikipedia.org/wiki/Treiber_stack#Correctness

On platforms with TRUE LL/SC atomics (e.g. Arm), this can be implemented correctly (tho might require custom asm? Unsure the state of things today, but see #180 and changes made in #315).

However it looks like this trick (again, I'm out of the loop) is to allow this in cases where the platform supports atomics that are LARGER than pointer widths, so you can CAS a pointer AND a unique tag to avoid the ABA problem, or at least make it sufficiently rare.

[Dirbaio]

reading more about it, I think i'm somewhat comfortable with the x64 impl being sound if it uses AtomicU128. Shame it's nightly-only but it's better than nothing :)

[reitermarkus]

I think the trick here is that the trieber stack is susceptible to the ABA problem: > https://en.wikipedia.org/wiki/Treiber_stack#Correctness

Thanks for the link, I understand now what the problem is and how using a value twice the size of the pointer width fixes it.

I have added an example explaining how it works, which is hopefully easy to follow.

I guess technically it's still possible to be incorrect if one threads pops/pushes the top of the stack usize::MAX times between another's load and cas, but that may be practically impossible.

do we know why the current code is impl'd only for x86?

I would expect because AtomicI128 is still unstable, i.e. this only works on nightly or when using portable-atomic.