b9b615b425
pthread_cond_wait() should be an atomic operation in the mutex lock/unlock. Since the sched_lock() has been wrongly deleted in the previous commit, the context switch will occurred after the mutex was unlocked: -------------------------------------------------------------------- Task1(Priority 100) | Task2(Priority 101) | pthread_mutex_lock(mutex); | | | pthread_cond_wait(cond, mutex) | | | | | | | | ->enter_critical_section() | | ->pthread_mutex_give(mutex) | ----> pthread_mutex_lock(mutex); // contex switch to high priority task | | pthread_cond_signal(cond); // signal before wait | | <---- pthread_mutex_unlock(mutex); // switch back to original task | ->pthread_sem_take(cond->sem)| // try to wait the signal, Deadlock. | ->leave_critical_section() | | | ->pthread_mutex_take(mutex) | | | pthread_mutex_lock(mutex); | --------------------------------------------------------------------- This PR will bring back sched_lock()/sched_unlock() to avoid context switch to ensure atomicity Signed-off-by: chao an <anchao@xiaomi.com> |
||
---|---|---|
.. | ||
addrenv | ||
clock | ||
environ | ||
group | ||
init | ||
irq | ||
misc | ||
module | ||
mqueue | ||
paging | ||
pthread | ||
sched | ||
semaphore | ||
signal | ||
task | ||
timer | ||
tls | ||
wdog | ||
wqueue | ||
Kconfig | ||
Makefile |