Lines Matching full:be
16 Any number of workqueues can be defined (limited only by available RAM). Each
24 thread is configurable, allowing it to be either cooperative or preemptive
31 A workqueue must be initialized before it can be used. This sets its queue to
40 caller need not be concerned that an item may be processing when the
56 delayable work is scheduled, should be avoided to prevent race conditions
63 Any number of **work items** can be defined. Each work item is referenced
71 A work item must be initialized before it can be used. This records the work
74 A work item may be **queued** (:c:enumerator:`K_WORK_QUEUED`) by submitting it to a
80 other items in the queue, a queued work item may be processed quickly or it
83 A delayable work item may be **scheduled** (:c:enumerator:`K_WORK_DELAYED`) to a
86 A work item will be **running** (:c:enumerator:`K_WORK_RUNNING`) when it is running
87 on a work queue, and may also be **canceling** (:c:enumerator:`K_WORK_CANCELING`)
88 if it started running before a thread has requested that it be cancelled.
90 A work item can be in multiple states; for example it can be:
96 * scheduled to be submitted to a (possibly different) queue
102 operations that are potentially blocking (e.g. taking a semaphore) must be
106 The single argument that is passed to a handler function can be ignored if it
108 the work it is to perform, the work item can be embedded in a larger data
114 workqueue whenever work needs to be performed. If an ISR or a thread attempts
125 A pending work item *must not* be altered until the item has been processed
126 by the workqueue thread. This means a work item must not be re-initialized
128 handler function needs to perform its work must not be altered until
136 An ISR or a thread may need to schedule a work item that is to be processed
137 only after a specified period of time, rather than immediately. This can be
138 done by **scheduling** a **delayable work item** to be submitted to a
142 record when and where the item should be submitted.
193 have to be valid and cannot be modified for a complete triggered work
199 Otherwise the cancellation cannot be performed.
210 Additional workqueues should only be defined when it is not possible
212 incurs a significant cost in memory footprint. A new workqueue can be
228 :c:func:`k_work_queue_start`. The stack area must be defined using
250 rescheduling can be controlled by the optional final parameter; see
253 The following API can be used to interact with a workqueue:
255 * :c:func:`k_work_queue_drain()` can be used to block the caller until the
258 thread or ISR are rejected. The restriction on submitting more work can be
263 item will silently fail to be submitted.
271 be initialized by calling :c:func:`k_work_init`, unless it is defined using
275 An initialized work item can be submitted to the system workqueue by
282 unchanged and the associated error message will not be printed.
317 The following API can be used to check the status of or synchronize with the
326 * :c:func:`k_work_flush()` may be invoked from threads to block until the work
329 executed. This may or may not be successful. This is safe to invoke
331 * :c:func:`k_work_cancel_sync()` may be invoked from threads to block until
334 can be used after :c:func:`k_work_cancel()` is invoked (from an ISR)` to
341 :c:struct:`k_work_delayable`. It must be initialized by calling
345 deadline should be extended if a new event occurs. An example is collecting
350 schedules work to be executed at a specific time or after a delay. Further
352 will not change the time at which the item will be submitted to its queue.
370 The helper function :c:func:`k_work_delayable_from_work()` can be used to get
374 The following additional API can be used to check the status of or synchronize
390 While the state of both regular and delayable work items can be determined
395 can be invoked from thread context to wait until the requested state has been
398 These APIs must be provided with a :c:struct:`k_work_sync` object that has no
400 synchronization objects. These objects should not be allocated on a stack if
415 be a flag indicating that work needs to be done, or a shared object that is
418 For simple flags :ref:`atomic_v2` may be sufficient. In other cases spin
420 :c:struct:`k_mutex` , ...) may be used to ensure data races don't occur.
445 Be aware that if the lock is held by a thread with a lower priority than the
448 delayable work item is preferred, and the work should be (re-)scheduled with a
454 to notify the application that the work could not be performed.
463 application/driver when the cancel is initiated, would be required to detect
475 happens the work will not be executed, which could cause a subsystem that is
485 There may be good reason to believe that a return value indicating that the
504 The workqueue API is designed to be safe when invoked from multiple threads
513 indication can be obsolete by the time the test is returned, and a "not-busy"
514 indication can also be wrong if work is submitted from multiple contexts, or
519 that can be checked by the handler to confirm whether there is work to be
522 are submitted, you may be able to have everything done in the work handler
535 ISR to a shared thread. This allows the interrupt-related processing to be