Lines Matching refs:lock
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:
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,
449 non-zero delay to allow the thread holding the lock to make progress.
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
528 submit the work while you're checking (generally because you're holding a lock