mirror of
https://github.com/zephyrproject-rtos/zephyr
synced 2025-09-02 17:53:00 +00:00
The k_mutex is a priority-inheriting mutex, so on unlock it's possible that a thread's priority will be lowered. Make this a reschedule point so that reasoning about thread priorities is easier (possibly at the cost of performance): most users are going to expect that the priority elevation stops at exactly the moment of unlock. Note that this also reorders the code to fix what appear to be obvious race conditions. After the call to z_ready_thread(), that thread may be run (e.g. by an interrupt preemption or on another SMP core), yet the return value and mutex weren't correctly set yet. The spinlock was also prematurely released. Fixes #20802 Signed-off-by: Andy Ross <andrew.j.ross@intel.com> |
||
---|---|---|
.. | ||
include | ||
atomic_c.c | ||
CMakeLists.txt | ||
compiler_stack_protect.c | ||
device.c | ||
errno.c | ||
fatal.c | ||
futex.c | ||
idle.c | ||
init.c | ||
Kconfig | ||
Kconfig.power_mgmt | ||
mailbox.c | ||
mem_domain.c | ||
mem_slab.c | ||
mempool.c | ||
msg_q.c | ||
mutex.c | ||
pipes.c | ||
poll.c | ||
queue.c | ||
sched.c | ||
sem.c | ||
smp.c | ||
stack.c | ||
system_work_q.c | ||
thread_abort.c | ||
thread.c | ||
timeout.c | ||
timer.c | ||
userspace_handler.c | ||
userspace.c | ||
version.c | ||
work_q.c |