This restores a pre-existing design decision to implement both
blocking and non-blocking mutex locking with the same code. Those
implementations have been split prior to the introduction of
the `core_mutex_priority_inheritance` module when `mutex_trylock()`
indeed was trivial. This decision didn't age well, so undo it.
Presently, RIOT just emits a warning when a stack overflow is
encountered but still resumes execution. In my view, execution should be
aborted as the detection of a stack overflows via the heuristic provided
by the scheduler is an unrecoverable error.
I ran into this while performing automated tests of a RIOT application
where a stack overflow occurred but I only noticed this after inspecting
the application output more closely.
Similar to SSP failures, I added crash_code for stack overflows.
This fixes https://github.com/RIOT-OS/RIOT/issues/18545 as the code
previously relied on `sched_change_priority()` not directly scheduling
a new thread while IRQs are disabled, but rather later when IRQs are
restored. This is true for Cortex-M MCUs (where the PendSV IRQ is used
to trigger the scheduler), but not e.g. for AVR.
An `1 << x` with `x >= 15` is undefined behavior on 8-bit / 16-bit
machines (which typically have `sizeof(int) == 2`).
Using `1UL << x` is safe for `x <= 31`, which is large enough to make
use of the full 32 bits in `runqueue_bitcache`.
In addition, a `static_assert()` is added to enforce that
`SCHED_PRIO_LEVELS` is never set to anything larger than 32.
This is intended for the bootloader module where we don't enter thread
mode, so mutex must never attempt to switch context.
Instead use a simple busy wait that is enough to make the possible mutex
users (e.g. interrupt based SPI) in bootloader mode work.
Use `uintptr_t` for arithmetic rather than `const char *` to fix the
following warning:
> comparePointers: Subtracting pointers that point to different objects
- activate THREAD_CREATE_STACKTEST also if test_utils_print_stack_usage
is used
- make thread_measure_stack_free() available unconditionally
- if DEVELHELP is active, call test_utils_print_stack_usage() on any
thread exit
- if DEVELHELP is active, call test_utils_print_stack_usage() after main
for the idle thread, if that is used
Replace use of C11 atomics with atomic utils. This fixes
> error: address argument to atomic operation must be a pointer to a
> trivially-copyable type ('_Atomic(int) *' invalid)
error when compiling on AVR with LLVM.