Blame view
Documentation/scheduler/completion.txt
9.83 KB
202799be4 doc: brief user d... |
1 2 3 4 5 6 7 8 9 |
completions - wait for completion handling ========================================== This document was originally written based on 3.18.0 (linux-next) Introduction: ------------- If you have one or more threads of execution that must wait for some process |
7085f6c35 docs/completion.t... |
10 11 12 |
to have reached a point or a specific state, completions can provide a race-free solution to this problem. Semantically they are somewhat like a pthread_barrier and have similar use-cases. |
202799be4 doc: brief user d... |
13 |
|
7085f6c35 docs/completion.t... |
14 |
Completions are a code synchronization mechanism which is preferable to any |
202799be4 doc: brief user d... |
15 |
misuse of locks. Any time you think of using yield() or some quirky |
7085f6c35 docs/completion.t... |
16 |
msleep(1) loop to allow something else to proceed, you probably want to |
202799be4 doc: brief user d... |
17 |
look into using one of the wait_for_completion*() calls instead. The |
4988aaa6e doc: completion: ... |
18 |
advantage of using completions is clear intent of the code, but also more |
202799be4 doc: brief user d... |
19 20 21 22 |
efficient code as both threads can continue until the result is actually needed. Completions are built on top of the generic event infrastructure in Linux, |
7085f6c35 docs/completion.t... |
23 24 |
with the event reduced to a simple flag (appropriately called "done") in struct completion that tells the waiting threads of execution if they |
202799be4 doc: brief user d... |
25 |
can continue safely. |
4988aaa6e doc: completion: ... |
26 |
As completions are scheduling related, the code is found in |
202799be4 doc: brief user d... |
27 28 29 30 31 32 |
kernel/sched/completion.c - for details on completion design and implementation see completions-design.txt Usage: ------ |
4988aaa6e doc: completion: ... |
33 |
There are three parts to using completions, the initialization of the |
202799be4 doc: brief user d... |
34 |
struct completion, the waiting part through a call to one of the variants of |
4988aaa6e doc: completion: ... |
35 |
wait_for_completion() and the signaling side through a call to complete() |
202799be4 doc: brief user d... |
36 37 38 39 40 41 42 43 44 45 46 47 48 49 |
or complete_all(). Further there are some helper functions for checking the state of completions. To use completions one needs to include <linux/completion.h> and create a variable of type struct completion. The structure used for handling of completions is: struct completion { unsigned int done; wait_queue_head_t wait; }; providing the wait queue to place tasks on for waiting and the flag for indicating the state of affairs. |
4988aaa6e doc: completion: ... |
50 |
Completions should be named to convey the intent of the waiter. A good |
202799be4 doc: brief user d... |
51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 |
example is: wait_for_completion(&early_console_added); complete(&early_console_added); Good naming (as always) helps code readability. Initializing completions: ------------------------- Initialization of dynamically allocated completions, often embedded in other structures, is done with: void init_completion(&done); Initialization is accomplished by initializing the wait queue and setting the default state to "not available", that is, "done" is set to 0. The re-initialization function, reinit_completion(), simply resets the done element to "not available", thus again to 0, without touching the |
7085f6c35 docs/completion.t... |
73 |
wait queue. Calling init_completion() twice on the same completion object is |
202799be4 doc: brief user d... |
74 75 76 77 78 79 80 81 82 83 84 85 86 |
most likely a bug as it re-initializes the queue to an empty queue and enqueued tasks could get "lost" - use reinit_completion() in that case. For static declaration and initialization, macros are available. These are: static DECLARE_COMPLETION(setup_done) used for static declarations in file scope. Within functions the static initialization should always use: DECLARE_COMPLETION_ONSTACK(setup_done) suitable for automatic/local variables on the stack and will make lockdep |
4988aaa6e doc: completion: ... |
87 |
happy. Note also that one needs to make *sure* the completion passed to |
202799be4 doc: brief user d... |
88 89 |
work threads remains in-scope, and no references remain to on-stack data when the initiating function returns. |
4988aaa6e doc: completion: ... |
90 91 92 93 94 95 |
Using on-stack completions for code that calls any of the _timeout or _interruptible/_killable variants is not advisable as they will require additional synchronization to prevent the on-stack completion object in the timeout/signal cases from going out of scope. Consider using dynamically allocated completions when intending to use the _interruptible/_killable or _timeout variants of wait_for_completion(). |
202799be4 doc: brief user d... |
96 97 98 99 100 101 102 |
Waiting for completions: ------------------------ For a thread of execution to wait for some concurrent work to finish, it calls wait_for_completion() on the initialized completion structure. A typical usage scenario is: |
7085f6c35 docs/completion.t... |
103 |
struct completion setup_done; |
202799be4 doc: brief user d... |
104 |
init_completion(&setup_done); |
4988aaa6e doc: completion: ... |
105 |
initialize_work(...,&setup_done,...) |
202799be4 doc: brief user d... |
106 107 |
/* run non-dependent code */ /* do setup */ |
4988aaa6e doc: completion: ... |
108 |
wait_for_completion(&setup_done); complete(setup_done) |
202799be4 doc: brief user d... |
109 |
|
4988aaa6e doc: completion: ... |
110 |
This is not implying any temporal order on wait_for_completion() and the |
202799be4 doc: brief user d... |
111 112 |
call to complete() - if the call to complete() happened before the call to wait_for_completion() then the waiting side simply will continue |
4988aaa6e doc: completion: ... |
113 114 |
immediately as all dependencies are satisfied if not it will block until completion is signaled by complete(). |
202799be4 doc: brief user d... |
115 |
|
7085f6c35 docs/completion.t... |
116 |
Note that wait_for_completion() is calling spin_lock_irq()/spin_unlock_irq(), |
202799be4 doc: brief user d... |
117 |
so it can only be called safely when you know that interrupts are enabled. |
7085f6c35 docs/completion.t... |
118 119 |
Calling it from hard-irq or irqs-off atomic contexts will result in hard-to-detect spurious enabling of interrupts. |
202799be4 doc: brief user d... |
120 121 122 123 |
wait_for_completion(): void wait_for_completion(struct completion *done): |
7085f6c35 docs/completion.t... |
124 |
The default behavior is to wait without a timeout and to mark the task as |
202799be4 doc: brief user d... |
125 |
uninterruptible. wait_for_completion() and its variants are only safe |
4988aaa6e doc: completion: ... |
126 127 128 129 |
in process context (as they can sleep) but not in atomic context, interrupt context, with disabled irqs. or preemption is disabled - see also try_wait_for_completion() below for handling completion in atomic/interrupt context. |
202799be4 doc: brief user d... |
130 |
As all variants of wait_for_completion() can (obviously) block for a long |
4988aaa6e doc: completion: ... |
131 |
time, you probably don't want to call this with held mutexes. |
202799be4 doc: brief user d... |
132 133 134 135 136 137 138 139 140 141 142 143 144 145 |
Variants available: ------------------- The below variants all return status and this status should be checked in most(/all) cases - in cases where the status is deliberately not checked you probably want to make a note explaining this (e.g. see arch/arm/kernel/smp.c:__cpu_up()). A common problem that occurs is to have unclean assignment of return types, so care should be taken with assigning return-values to variables of proper type. Checking for the specific meaning of return values also has been found to be quite inaccurate e.g. constructs like |
4988aaa6e doc: completion: ... |
146 |
if (!wait_for_completion_interruptible_timeout(...)) would execute the same |
202799be4 doc: brief user d... |
147 148 149 150 |
code path for successful completion and for the interrupted case - which is probably not what you want. int wait_for_completion_interruptible(struct completion *done) |
4988aaa6e doc: completion: ... |
151 |
This function marks the task TASK_INTERRUPTIBLE. If a signal was received |
7085f6c35 docs/completion.t... |
152 |
while waiting it will return -ERESTARTSYS; 0 otherwise. |
202799be4 doc: brief user d... |
153 154 155 |
unsigned long wait_for_completion_timeout(struct completion *done, unsigned long timeout) |
4988aaa6e doc: completion: ... |
156 157 |
The task is marked as TASK_UNINTERRUPTIBLE and will wait at most 'timeout' (in jiffies). If timeout occurs it returns 0 else the remaining time in |
7085f6c35 docs/completion.t... |
158 159 160 161 |
jiffies (but at least 1). Timeouts are preferably calculated with msecs_to_jiffies() or usecs_to_jiffies(). If the returned timeout value is deliberately ignored a comment should probably explain why (e.g. see drivers/mfd/wm8350-core.c wm8350_read_auxadc()) |
202799be4 doc: brief user d... |
162 163 164 |
long wait_for_completion_interruptible_timeout( struct completion *done, unsigned long timeout) |
7085f6c35 docs/completion.t... |
165 166 167 168 |
This function passes a timeout in jiffies and marks the task as TASK_INTERRUPTIBLE. If a signal was received it will return -ERESTARTSYS; otherwise it returns 0 if the completion timed out or the remaining time in jiffies if completion occurred. |
202799be4 doc: brief user d... |
169 |
|
7085f6c35 docs/completion.t... |
170 171 172 |
Further variants include _killable which uses TASK_KILLABLE as the designated tasks state and will return -ERESTARTSYS if it is interrupted or else 0 if completion was achieved. There is a _timeout variant as well: |
202799be4 doc: brief user d... |
173 174 175 176 |
long wait_for_completion_killable(struct completion *done) long wait_for_completion_killable_timeout(struct completion *done, unsigned long timeout) |
4988aaa6e doc: completion: ... |
177 |
The _io variants wait_for_completion_io() behave the same as the non-_io |
202799be4 doc: brief user d... |
178 |
variants, except for accounting waiting time as waiting on IO, which has |
4988aaa6e doc: completion: ... |
179 |
an impact on how the task is accounted in scheduling stats. |
202799be4 doc: brief user d... |
180 181 182 183 184 185 186 187 |
void wait_for_completion_io(struct completion *done) unsigned long wait_for_completion_io_timeout(struct completion *done unsigned long timeout) Signaling completions: ---------------------- |
4988aaa6e doc: completion: ... |
188 189 190 |
A thread that wants to signal that the conditions for continuation have been achieved calls complete() to signal exactly one of the waiters that it can continue. |
202799be4 doc: brief user d... |
191 192 |
void complete(struct completion *done) |
4988aaa6e doc: completion: ... |
193 |
or calls complete_all() to signal all current and future waiters. |
202799be4 doc: brief user d... |
194 195 196 197 198 199 200 201 202 203 204 |
void complete_all(struct completion *done) The signaling will work as expected even if completions are signaled before a thread starts waiting. This is achieved by the waiter "consuming" (decrementing) the done element of struct completion. Waiting threads wakeup order is the same in which they were enqueued (FIFO order). If complete() is called multiple times then this will allow for that number of waiters to continue - each call to complete() will simply increment the done element. Calling complete_all() multiple times is a bug though. Both |
4988aaa6e doc: completion: ... |
205 |
complete() and complete_all() can be called in hard-irq/atomic context safely. |
202799be4 doc: brief user d... |
206 207 |
There only can be one thread calling complete() or complete_all() on a |
4988aaa6e doc: completion: ... |
208 |
particular struct completion at any time - serialized through the wait |
202799be4 doc: brief user d... |
209 210 211 212 |
queue spinlock. Any such concurrent calls to complete() or complete_all() probably are a design bug. Signaling completion from hard-irq context is fine as it will appropriately |
4988aaa6e doc: completion: ... |
213 |
lock with spin_lock_irqsave/spin_unlock_irqrestore and it will never sleep. |
202799be4 doc: brief user d... |
214 215 216 217 |
try_wait_for_completion()/completion_done(): -------------------------------------------- |
4988aaa6e doc: completion: ... |
218 219 |
The try_wait_for_completion() function will not put the thread on the wait queue but rather returns false if it would need to enqueue (block) the thread, |
7085f6c35 docs/completion.t... |
220 |
else it consumes one posted completion and returns true. |
202799be4 doc: brief user d... |
221 |
|
4988aaa6e doc: completion: ... |
222 |
bool try_wait_for_completion(struct completion *done) |
202799be4 doc: brief user d... |
223 |
|
7085f6c35 docs/completion.t... |
224 225 226 227 |
Finally, to check the state of a completion without changing it in any way, call completion_done(), which returns false if there are no posted completions that were not yet consumed by waiters (implying that there are waiters) and true otherwise; |
202799be4 doc: brief user d... |
228 |
|
4988aaa6e doc: completion: ... |
229 |
bool completion_done(struct completion *done) |
202799be4 doc: brief user d... |
230 231 |
Both try_wait_for_completion() and completion_done() are safe to be called in |
4988aaa6e doc: completion: ... |
232 |
hard-irq or atomic context. |