Lines Matching refs:thread

10 A :dfn:`workqueue` is a kernel object that uses a dedicated thread to process
13 used by an ISR or a high-priority thread to offload non-urgent processing
14 to a lower-priority thread so it does not impact time-sensitive processing.
23 * A **thread** that processes the work items in the queue. The priority of the
24   thread is configurable, allowing it to be either cooperative or preemptive
27 Regardless of workqueue thread priority the workqueue thread will yield
32 empty and spawns the workqueue's thread.  The thread runs forever, but sleeps
67 executed by the workqueue's thread when the work item is processed. This
75 workqueue by an ISR or a thread.  Submitting a work item appends the work item
76 to the workqueue's queue.  Once the workqueue's thread has processed all of
77 the preceding work items in its queue the thread will remove the next work
79 the scheduling priority of the workqueue's thread, and the work required by
88 if it started running before a thread has requested that it be cancelled.
93 * marked canceling (because a thread used :c:func:`k_work_cancel_sync()` to
114 workqueue whenever work needs to be performed. If an ISR or a thread attempts
126     by the workqueue thread. This means a work item must not be re-initialized
136 An ISR or a thread may need to schedule a work item that is to be processed
174 a dedicated thread waiting or actively polling for a poll event.
196 An ISR or a thread may **cancel** a triggered work item it has submitted
226 thread, initializing the :c:struct:`k_work_q`, either zeroing its
249 In addition the queue identity and certain behavior related to thread
257   thread are accepted while a queue is draining, but work items from any other
258   thread or ISR are rejected.  The restriction on submitting more work can be
260   blocking thread to perform additional work while the queue is "plugged".
395 can be invoked from thread context to wait until the requested state has been
410 Sometimes the data a work item must process is naturally thread-safe, for
411 example when it's put into a :c:struct:`k_queue` by some thread and processed
412 in the work thread. More often external synchronization is required to avoid
413 data races: cases where the work thread might inspect or manipulate shared
414 state that's being accessed by another thread or interrupt.  Such state might
416 filled by an ISR or thread and read by the work handler.
419 locks (:c:struct:`k_spinlock`) or thread-aware locks (:c:struct:`k_sem`,
423 work thread to sleep will starve other work queue items, which may need to
445 Be aware that if the lock is held by a thread with a lower priority than the
446 work queue the resubmission may starve the thread that would release the lock,
449 non-zero delay to allow the thread holding the lock to make progress.
499 cannot guarantee that the work thread is not accessing work-related state.
535 ISR to a shared thread. This allows the interrupt-related processing to be
538 manage an additional thread to do the processing.