feat(cordyceps): Initial support for non-CAS targets

[jamesmunns]

This PR is a first attempt to allow building of cordyceps on non-CAS enabled targets, such as thumbv6m-none-eabi/Cortex-M0+/rp2040.

Doing this as a first feature, prior to implementing a non-atomic and critical_section based version of TransferStack, in service of embassy-rs/embassy#4035.

Rather than making a default-on "CAS" feature, we instead gate on cfg(target_has_atomic = "ptr"), which was stabilized in 1.60, which currently has the meaning of "this target has CAS". This automatically gates-out TransferStack and MpscQueue, while the "mutable" collections can still be used.

Right now the cfg gating is a little scattershot, I wanted to open this to discuss, if you'd like me to clean things up a bit to group the CAS-ful parts, I'm happy to do so.

[hawkw]

Would you mind elaborating a bit on the rationale for doing this by cfg-gating out the atomic structures on these targets, rather than using something like portable-atomic, which we use elsewhere?

For the record, I'm not suggesting that just disabling these APIs on non-CAS platforms is the wrong approach, I'm just curious about why it's the right one. My guess is that this is because portable-atomic's fallback on these platforms is a mutex-like thing, making the lock free structures suddenly...not lock-free, and hand-implementing a critical-section/mutex-y version of the structure would allow better control of where critical sections occur etc?

[jamesmunns]

My guess is that this is because portable-atomic's fallback on these platforms is a mutex-like thing, making the lock free structures suddenly...not lock-free, and hand-implementing a critical-section/mutex-y version of the structure would allow better control of where critical sections occur etc?

Yep! That's exactly it. A naiive "drop in p-a" impl would be decidedly not-great for all structures, so my plan was to make the current lib build, notching out unsupported structures entirely, then in a second pass/PR, re-implement at least TransferStack, providing a pretty much separate (but API compatible!) implementation that uses a larger critical section when interacting with the list. This way, we have a single, sliiiightly larger, critical section, rather than a couple of smaller ones.

[jamesmunns]

For what it's worth, bbqueue (the stable version) went the p-a route, and I realized that it was unsatisfying, because it meant doing multiple separate critical sections for ringbuffer ops (emulating the atomic lock-free algorithm).

For bbq2, I ended up making a separate trait for Coordination, though I'm not sure whether that's the route to go for in TransferStack. That's why I wanted to land this PR first, to first discuss "is it a good idea to support non-atomic targets" (and a little bit "are we okay with not always supporting non-atomic targets 1:1"), and the next PR can discuss "is this specific impl of TransferStack a good way to do so".

[hawkw]

Yeah, that makes sense. I'm on board with the initial goal of just getting the crate to build for those targets at all!

[jamesmunns]

@hawkw is this good to merge, or did you want to take another pass on it?

[hawkw]

@hawkw is this good to merge, or did you want to take another pass on it?

sorry, i wanted to leave a few suggestions on the feature-flagging implementation. give me a sec!

[hawkw]

I had a few minor suggestions on how we could make the cfg-gating a bit more ergonomic for future changes to the cfg-gated structures, and a couple small tweaks to the CI job. Other than that, this looks good!