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.
This adds a simple macro to check (at C level) whether a given
expression is proven to be compile time constant and suitable for
constant folding. This allows writing code like this:
```C
int gpio_read(gpio_t pin) {
if (IS_CT_CONSTANT(pin)) {
/* this implementation should even be able to use the port and
* pin number as immediate in inline assembly */
}
else {
/* less efficient implementation that cannot use port and pin
* number as immediate in inline assembly */
}
}
```
This provides the same functionality as `static_assert()` provided by
C11 and has no advantages compared to it. Hence, encourage users to use
standard C functionality instead.
For the caller there should be no difference if there is no message
in the queue and if there can't be a message in the queue.
The current API works as one would expect if there is a message queue,
but once called from a thread that does not have a message queue
configured, code that does
while (msg_avail())
will end up in an infinite loop.
Remove this foot-gun from the API by making the return value of
msg_avail() independend of the availability of a message queue.
`WITHOUT_PEDANTIC(expr)` disables `-Wpedantic` for `expr`, but switches
back to the previous diagnostic settings afterwards. This helps defining
macros that are not strictly ISO compliant without having to drop the
`-Wpedantic` flag entirely.
`DECLARE_CONSTANT(identifier, const_expr)` declares an anonymous `enum`
constant named `identifier` and assigns it the value `const_expr`. Here,
`const_expr` has to be a compile time constant, but is not needed to be
an integer constant expression. It basically is a tool to magically
convert a non-integer constant expression into a integer constant
expression.
Calculate the size of the element based on the array given, not based
on the element pointer.
The element might as well be given as a `void *` via a callback.
In that case, if the user forgets to cast the `void *` to the array
element type, the calculation returns false values.
Disarm this foot gun by basing the element size off the given array.
This prevents gcc from figuring out that an XFA that has been
initialized in the same file is technically empty when the compilation
unit is seen by itself. This happened with gcc 10.1.0 on msp430-elf.
Due to limited compatibility with C, we cannot use the inline mutex_trylock
implementation for C++. Instead, we provide a mutex_trylock_ffi() intended for
foreign function interfaces. This should also benefit rust users.
Add a version of `mutex_lock()` that can be canceled with the obvious name
`mutex_lock_cancelable()`. This function returns `0` on success, and
`-ECANCELED` when the calling thread was unblocked via a call to
`mutex_cancel()` (and hence without obtaining the mutex).
This is intended to simplify the implementation of `xtimer_mutex_lock_timeout()`
and to implement `ztimer_mutex_lock_timeout()`.
- Split out handling of the blocking code path of mutex_lock() into a static
`_block()` function. This improves readability a bit and will ease review of
a follow up PR.
- Return `void` instead of `int`.
- Use static inline function for `mutex_try_lock()`
- The implementation is trivial enough with the inline-able IRQ API to just
always be inline-ed
- Rename `_mutex_lock()` to `mutex_lock()` and drop the blocking parameter
- This was possible to the stand-alone `mutex_try_lock()` implementation
- This yields a measurable performance bump
Currently it is not possible to check if a message was sent over a bus
or if it was send the usual way using `msg_send()`.
This adds a flag to the `sender_pid` if the message was sent over a bus.
`MAXTHREADS` is currently set to 32, so there is still plenty of room in
the PID space. (`kernel_pid_t` is `int16_t`)
The message type for bus message type is already accessed through a getter
function, so it's just consistent to do the same for sender_pid.
Verified that each warning generated by -Wcast-align is indeed a false positive
and used an (intermediate) cast to `uintptr_t` to silence the warnings.
container_of() is safe to use in regard to alignment requirements, when used
correctly. Using `uintptr_t` instead of `char *` for applying the offset results
in -Wcast-align not complaining.
Separate thread names from DEVELHELP so thread names can be
enabled in non-development/debug builds when required/desired.
THREAD_NAMES will be enabled by default then DEVELHELP is set to 1.
