no-std select!

[arcnmx]

While #1891 adds minimal support for the async-await feature flag on no_std platforms by enabling the trivial macros and pieces that can work without modification, select! and the rng implementation detail behind it remain the odd one out. This PR aims to address that.

To reiterate a few points on why changes are necessary and what design decisions need to be made here, armv6m and some other archs only have AtomicUsize::{load, store} rather than full CAS or double width atomics. This requires reducing the xorshift state width depending on target pointer size and also being okay with the state potentially repeating in the cases where calls overlap during the load+store and clobber each other. Given that the randomness requirements here are rather weak (and just in place to prevent executor time/scheduling exhaustion), I believe this shouldn't be much of a problem in practice even under pathological workloads (also no_std systems will likely only have one global single-threaded executor anyway?).

This is more of an RFC than a draft to pitch whether something along these lines could be accepted. Some potential points I can come up with against it:

• no_std futures are currently unsupported by stable rust and thus effort shouldn't be made to support them
• complicates the rng by adding no_std specific logic
  • somewhat mitigated by continuing to use the existing approach when libstd is available, so only affects "unsupported" platforms?
• a proposed select_biased!() macro won't need any special handling and will work as-is on std and nostd alike while meeting many of the same needs
• the details around a deterministic seed and atomic race conditions are more of a concern than I'm making them out to be

[Nemo157]

Since different pointer widths use different algorithms it would be good to move this comment to them. It looks like it's currently xorshift64*, xorshift32 and non-standard xorshift16 (is there a reference for the constants chosen for this? the xorshift paper only appears to have tables for 32 and 64).

[arcnmx]

Yeah, this should definitely be documented and a conscious decision made for each. I picked something random just to get the concept up to show, and to discuss whether plain xorshift32 is "good enough" (it even feels like xorshift64* is overkill but I left it as-is considering it's the existing implementation and unlikely to matter on 64bit targets anyway). The most relevant discussion of 16bit variants I've come across is here, my target platform in mind here is msp430 (are there any other 16bit rust targets?).

[cramertj]

I think this is actually fine-- multiple threads can't be polling the same future at once, so all this means is that the ordering of two unrelated select!s running at the same time will be the same.

[arcnmx]

That's a good point, though I think I framed the issue poorly in the comment. While I don't think it's a big deal because you will always eventually make progress, and the problem seems somewhat convoluted and only really scales if you have tons of threads, what I believe can happen is:

rng state = 1
thread1: load state = 1
thread2: load state = 1
thread2: shuffle + store state = 2
thread2: load state = 2
thread2: shuffle + store state = 3
thread1: shuffle + store state = 2
thread2: load state = 2 // oh no state was clobbered and the sequence jumped backward from thread2's PoV
thread2: shuffle + store state = 3

[Matthias247]

Different idea, which is less prescriptive: Offer users a mechanism to pass a random function to select as an additional parameter, and we just call that one. That would work on all platforms. Only on std the existing implementation without the additional parameter would exist, which would make use of the random function that uses TLS.

Benefit here is that users on no-std don't have to pay the overhead for atomics and a static variable if not required.

We can then also add select_unbiased! by passing a random function which does nothing - and which would be available everywhere.

The downside of this is that no-std users obviously wouldn't have a an API compatible select! without passing any additional arg. So maybe it's still worthwhile to add what is proposed here so that a trivial implementation exists, and add overloads for a configurable random for power-users which have more specific concerns?

[arcnmx]

Offer users a mechanism to pass a random function to select as an additional parameter, and we just call that one

This would be really nice, yeah.

We can then also add select_unbiased! by passing a random function which does nothing

I believe that would be select_biased!?

The downside of this is that no-std users obviously wouldn't have a an API compatible select! without passing any additional arg

While I personally don't care much for my own purposes/interests and would be fine with that api alone, it does seem beneficial to provide a default/fallback implementation if possible.

[arcnmx]

While this is less of a blocker now that select_biased! has landed, it still would be nice to offer the unbiased select! in no_std environments. I think I'm content with my implementation choices here so undrafted.

[Nemo157]

So, it turns out that DefaultHasher doesn't actually involve any randomness, so you could replace this with 13646096770106105413 (for the current algorithm backing it).

Alternatively, this could be changed to use RandomState instead of DefaultHasher so that there is actually some randomness injected. That should probably be a separate PR though.

[arcnmx]

Hm, yeah without randomness there's presumably little point in using a hasher at all, the seed generator may as well just be reduced to COUNTER.fetch_add(1) and give out sequential seeds at that point.

(note the linked fn returns a new seed per thread to initialize TLS with so replacing that literal line with a constant isn't equivalent, unless you meant I should change the const fn underneath to match)