Add portable_atomic_unsafe_force_critical_section cfg

[taiki-e]

Motivation

Some environments use storage of a type that atomic instructions don't work, as memory.

These storages are incompatible with LLVM atomic lowing, to perform atomic operations on those storages, some non-lock-free way must be used.

Discussions

There has been some discussion on this in esp-rs/esp-hal#2027 and its considered probably reasonable to provide a way to make sure the critical-section is always used (even when atomic CAS is available). (Aside from ESP-IDF, which is more complicated: esp-rs/esp-hal#2027 (comment))

(The above issue contains various discussions (e.g., discussions about trying to get a standard library to add something that violates its current guarantees, etc.) and TBH it is painful to track, so I'm opening this as an issue to track the actual work.)

Proposed Solution

Basically it would most likely be reasonable to implement what I mentioned in my first comment on that issue (esp-rs/esp-hal#2027 (comment)). i.e.,

• Add a cfg to always use the critical-section. (See the above comment about why this is not Cargo feature.)

I think it is reasonable to implement the simplest one, which appears to be uncontroversial, for now. (Initially there was some discussion about various optimizations, but I probably shouldn't have talked about them. The discussion was delayed and went off track...)

cc @MabezDev @ivmarkov

[ivmarkov]

I aggree 100%: the simplest possible unconditional feature (or a cfg) to always use a critical section.

[MabezDev]

I think your proposed solution is the simplest (and the best).