Lines Matching +full:has +full:- +full:lock
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.
19 A workqueue has the following key properties:
46 * The ability to wait until a work item has completed or a queue has been
76 to the workqueue's queue. Once the workqueue's thread has processed all of
88 if it started running before a thread has requested that it be cancelled.
119 A handler function is permitted to re-submit its work item argument
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
129 the handler function has finished executing.
147 triggered after the specified delay has elapsed. Once the timeout occurs the
152 underlying non-delayable work structure, which is not publicly accessible from
156 .. code-block:: c
171 call a user-defined function when a monitored resource becomes available
176 A triggered work item is a standard work item that has the following
196 An ISR or a thread may **cancel** a triggered work item it has submitted
213 justified if it is not possible for its work items to co-exist with
234 .. code-block:: c
256 work queue has no items left. Work items resubmitted from the workqueue
261 Note that draining a queue has no effect on scheduling or processing
273 compile-time.
284 .. code-block:: c
304 printk("Got error on device %s\n", the_device->name);
327 item has completed. It returns immediately if the work is not pending.
335 confirm completion of an ISR-initiated cancellation.
365 delay has not completed).
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
399 application-inspectable components but is needed to provide the
410 Sometimes the data a work item must process is naturally thread-safe, for
419 locks (:c:struct:`k_spinlock`) or thread-aware locks (:c:struct:`k_sem`,
422 If the selected lock mechanism can :ref:`api_term_sleep` then allowing the
424 make progress in order to get the lock released. Work handlers should try to
425 take the lock with its no-wait path. For example:
427 .. code-block:: c
434 if (k_mutex_lock(&parent->lock, K_NO_WAIT) != 0) {
440 /* do stuff under lock */
441 k_mutex_unlock(&parent->lock);
442 /* do stuff without lock */
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,
448 delayable work item is preferred, and the work should be (re-)scheduled with a
449 non-zero delay to allow the thread holding the lock to make progress.
456 Work items in isolation are self-locking, so you don't need to hold an
457 external lock just to submit or schedule them. Even if you use external state
458 protected by such a lock to prevent further resubmission, it's safe to do the
459 resubmit as long as you're sure that eventually the item will take its lock
462 take the lock some other self-locking state, such as an atomic flag set by the
476 animated by work handler activity to become non-responsive.
491 .. code-block:: c
493 /* If this fails, the work handler will check pub->active and
496 (void)k_work_cancel_delayable(&pub->timer);
499 cannot guarantee that the work thread is not accessing work-related state.
511 checking for a non-zero delay from
513 indication can be obsolete by the time the test is returned, and a "not-busy"
515 (for delayable work) if the deadline has completed but the work is still in
528 submit the work while you're checking (generally because you're holding a lock
534 Use the system workqueue to defer complex interrupt-related processing from an
535 ISR to a shared thread. This allows the interrupt-related processing to be