mirror of
https://github.com/zephyrproject-rtos/zephyr
synced 2025-08-08 03:57:28 +00:00
d89249dbc5
Originally, pthread_cond_signal() was written to yield even in circumstances where the current thread is at a cooperative priority and would not expect to be context-switched out until it blocks. This makes sense, as in most cases you want the newly signaled thread to get a chance to run as soon as possible. On further reflection (and also because it complicates the scheduler), I think that's wrong. The point to cooperative scheduling is that it allows the cooperative code to make synchronization assumptions about exactly when it might yield to other threads, and having arbitrary APIs be "preemption points" like this complicates that analysis significantly. Use _reschedule() like other code does. Signed-off-by: Andy Ross <andrew.j.ross@intel.com> |
||
|---|---|---|
| .. | ||
| base64 | ||
| crc | ||
| json | ||
| libc | ||
| mempool | ||
| posix | ||
| rbtree | ||
| ring_buffer | ||
| CMakeLists.txt | ||
| Kconfig | ||