mirror of
https://github.com/zephyrproject-rtos/zephyr
synced 2025-08-28 17:45:22 +00:00
03c1d28e6e
As discovered in https://github.com/zephyrproject-rtos/zephyr/issues/5952 ...a duplicate call to k_delayed_work_submit_to_queue() on a work item whose timeout had expired but which had not yet executed (i.e. it was pending in the queue for the active work queue thread) would fail, because the cancellation step wouldn't clear the PENDING bit, causing the resubmission to see the object in an invalid state. Trivially fixed by adding a bit clear. It also turns out that the behavior of the code doesn't match the docs, which state that a PENDING work item is not supposed to be cancelled at all. Fix the docs to remove that. And on yet further review, it turns out that there's no way to make a test like the one in the linked bug threadsafe. The work queue does no synchronization by design, so if the user code does no external synchronization it might very well clobber the running handler. Added a sentence to the docs to reflect this gotcha. Signed-off-by: Andy Ross <andrew.j.ross@intel.com> |
||
|---|---|---|
| .. | ||
| include | ||
| posix | ||
| alert.c | ||
| atomic_c.c | ||
| CMakeLists.txt | ||
| compiler_stack_protect.c | ||
| device.c | ||
| errno.c | ||
| idle.c | ||
| init.c | ||
| int_latency_bench.c | ||
| Kconfig | ||
| Kconfig.event_logger | ||
| 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 | ||
| stack.c | ||
| sys_clock.c | ||
| system_work_q.c | ||
| thread_abort.c | ||
| thread.c | ||
| timer.c | ||
| userspace_handler.c | ||
| userspace.c | ||
| version.c | ||
| work_q.c | ||