Lines Matching +full:wait +full:- +full:queue

2 Completions - "wait for completion" barrier APIs
6 -------------
8 If you have one or more threads that must wait for some kernel activity
10 race-free solution to this problem. Semantically they are somewhat like a
11 pthread_barrier() and have similar use-cases.
14 misuse of locks/semaphores and busy-loops. Any time you think of using
34 ------
38  - the initialization of the 'struct completion' synchronization object
39  - the waiting part through a call to one of the variants of wait_for_completion(),
40  - the signaling side through a call to complete() or complete_all().
46 it has to wait for it.
54 		struct swait_queue_head wait;
57 This provides the ->wait waitqueue to place tasks on for waiting (if any), and
58 the ->done completion flag for indicating whether it's completed or not.
72 -------------------------
75 structures that are assured to be alive for the life-time of the function/driver,
79 variants of wait_for_completion(), as it must be assured that memory de-allocation
81 have taken place, even if these wait functions return prematurely due to a timeout
87 	init_completion(&dynamic_object->done);
89 In this call we initialize the waitqueue and set ->done to 0, i.e. "not completed"
92 The re-initialization function, reinit_completion(), simply resets the
93 ->done field to 0 ("not done"), without touching the waitqueue.
98 most likely a bug as it re-initializes the queue to an empty queue and
99 enqueued tasks could get "lost" - use reinit_completion() in that case,
127 _killable() and _interruptible()) variants, the wait might complete
128 prematurely while the object might still be in use by another thread - and a return
142 ------------------------
144 For a thread to wait for some concurrent activity to finish, it
158 	/* run non-dependent code */		/* do setup */
163 the call to complete() - if the call to complete() happened before the call
170 Calling it from IRQs-off atomic contexts will result in hard-to-detect
173 The default behavior is to wait without a timeout and to mark the task as
176 interrupt context, with disabled IRQs, or preemption is disabled - see also
186 ------------------------------------------
189 most(/all) cases - in cases where the status is deliberately not checked you
194 so take care to assign return-values to variables of the proper type.
202 interrupted case - which is probably not what you want::
207 If a signal was received while waiting it will return -ERESTARTSYS; 0 otherwise::
211 The task is marked as TASK_UNINTERRUPTIBLE and will wait at most 'timeout'
216 to make the code largely HZ-invariant.
219 why (e.g. see drivers/mfd/wm8350-core.c wm8350_read_auxadc())::
224 TASK_INTERRUPTIBLE. If a signal was received it will return -ERESTARTSYS;
229 designated tasks state and will return -ERESTARTSYS if it is interrupted,
235 The _io variants wait_for_completion_io() behave the same as the non-_io
244 ----------------------
262 of waiters to continue - each call to complete() will simply increment the
267 particular 'struct completion' at any time - serialized through the wait
268 queue spinlock. Any such concurrent calls to complete() or complete_all()
277 --------------------------------------------
279 The try_wait_for_completion() function will not put the thread on the wait
280 queue but rather returns false if it would need to enqueue (block) the thread,