Support atomic CAS on no-std pre-v6 ARM targets (e.g., thumbv4t-none-eabi)

[taiki-e]

Pre-v6 ARM targets (except for Linux) don't support atomic CAS.

As far as I know, there are several ways to support this:

• Spinlock based on SWP instruction. (multi-core safety: yes)
  implementation: Support atomic CAS on no-std pre-v6 ARM using SWP instruction #27
  EDIT: this is broken on single-core + interrupt situations

• Disabling interrupts. (What we are currently doing for thumbv6m and other targets.) (multi-core safety: no)
  Is there a standardized way to do this? Maybe interrupt disable bits in CPSR?
  implementation: interrupt: Support no-std pre-v6 ARM targets #28

• Use atomic builtins. (Let the user implement the actual atomic logic.) (multi-core safety: implementation-dependent)
  See this comment for problems I am aware of.
  implementation: Add cfg to use __atomic_* builtins #30

• Optional feature to use 3rd party crate like critical-section. (Let the user implement the actual atomic logic.) (multi-core safety: no by default)
  However, critical-section 0.2 should be enabled only under the unsafe cfg because the default implementation is unsound on multi-core systems.
  Even on critical-section 1.0, it seems that this also needs to be unsafe because it has the same problems as the case using atomic builtins.

[Lokathor]

Speaking as the thumbv4t-none-eabi and armv4t-none-eabi maintainer:

• the SWP spinlock is fundamentally broken logically in single core + interrupt situations. At any given moment, the lock is not held and you can just do whatever you want, or the lock is held but you'll never get it (because the person running can't execute while you do) so spinning will never complete. The only thing that really works is for interrupt handler code to be forced ("somehow") to use something like a try_lock method and immediately give up on failure (because, again, the main thread holds the lock and can't release it while the interrupt handler is running).
• Interrupts can be turned off at the CPU level using CPSR but that's kinda touchy to mess with, and probably Rust shouldn't attempt to do that. Also, I don't think the standard library should ever automatically disable interrupts, but if it's for such a short period of time as a CAS then maybe it's okay. Also important: I'd have to look it up to be positive, but I'm 99% sure you can't mess with CPSR from User mode. And it's maybe unlikely that a program would bother to use User mode with no_std, but, they could, and then the CPSR disabling would break.
• The atomic builtins can be implemented (probably weak linked) within the compiler-builtins crate, so that's probably a good plan for having a default impl which people can override if they need. Of course they would probably be implemented by disabling interrupts using CPSR.
• 3rd party crates can always do whatever I guess.

[taiki-e]

@Lokathor Thanks for your comment!

the SWP spinlock is fundamentally broken logically in single core + interrupt situations. At any given moment, the lock is not held and you can just do whatever you want, or the lock is held but you'll never get it (because the person running can't execute while you do) so spinning will never complete.

Oh, that's really bad... Thanks for the detailed explanation!

I don't think the standard library should ever automatically disable interrupts, but if it's for such a short period of time as a CAS then maybe it's okay.

This crate's interrupt disabling-based implementation will only¹ be enabled if the end-user explicitly enables the unsafe cfg, so I think it's okay if we update the cfg documentation to make it clear that it disables interrupts.

Also important: I'd have to look it up to be positive, but I'm 99% sure you can't mess with CPSR from User mode. And it's maybe unlikely that a program would bother to use User mode with no_std, but, they could, and then the CPSR disabling would break.

Ah, that is indeed important. I think other targets have similar issues and we need to update the cfg documentation to mention it. (Since it requires explicitly enabling unsafe cfg anyway, I think it's okay as long as it's properly documented.)

The atomic builtins can be implemented (probably weak linked) within the compiler-builtins crate, so that's probably a good plan for having a default impl which people can override if they need.

Using a weak definition to provide a default implementation that can be overridden is a very interesting idea!

Footnotes

1. Except for AVR which is definitely single core and LLVM also generates code to disable interrupts in atomic ops by default. ↩

[taiki-e]

Updated docs by 5759f3c, and opened #28 to support disabling interrupts.

(That said, I think the full fix to this problem would require either atomic builtins or third-party crate support.)

[taiki-e]

(For atomic builtins, it is now tracked by #33)