]> CyberLeo.Net >> Repos - FreeBSD/FreeBSD.git/blob - share/man/man9/timeout.9
This commit was generated by cvs2svn to compensate for changes in r152390,
[FreeBSD/FreeBSD.git] / share / man / man9 / timeout.9
1 .\"     $NetBSD: timeout.9,v 1.2 1996/06/23 22:32:34 pk Exp $
2 .\"
3 .\" Copyright (c) 1996 The NetBSD Foundation, Inc.
4 .\" All rights reserved.
5 .\"
6 .\" This code is derived from software contributed to The NetBSD Foundation
7 .\" by Paul Kranenburg.
8 .\"
9 .\" Redistribution and use in source and binary forms, with or without
10 .\" modification, are permitted provided that the following conditions
11 .\" are met:
12 .\" 1. Redistributions of source code must retain the above copyright
13 .\"    notice, this list of conditions and the following disclaimer.
14 .\" 2. Redistributions in binary form must reproduce the above copyright
15 .\"    notice, this list of conditions and the following disclaimer in the
16 .\"    documentation and/or other materials provided with the distribution.
17 .\" 3. All advertising materials mentioning features or use of this software
18 .\"    must display the following acknowledgement:
19 .\"        This product includes software developed by the NetBSD
20 .\"        Foundation, Inc. and its contributors.
21 .\" 4. Neither the name of The NetBSD Foundation nor the names of its
22 .\"    contributors may be used to endorse or promote products derived
23 .\"    from this software without specific prior written permission.
24 .\"
25 .\" THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
26 .\" ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
27 .\" TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
28 .\" PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE
29 .\" LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
30 .\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
31 .\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
32 .\" INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
33 .\" CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
34 .\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
35 .\" POSSIBILITY OF SUCH DAMAGE.
36 .\"
37 .\" $FreeBSD$
38 .\"
39 .Dd September 8, 2005
40 .Dt TIMEOUT 9
41 .Os
42 .Sh NAME
43 .Nm timeout ,
44 .Nm untimeout ,
45 .Nm callout_handle_init ,
46 .Nm callout_init ,
47 .Nm callout_init_mtx ,
48 .Nm callout_stop ,
49 .Nm callout_drain ,
50 .Nm callout_reset ,
51 .Nm callout_pending ,
52 .Nm callout_active ,
53 .Nm callout_deactivate
54 .Nd execute a function after a specified length of time
55 .Sh SYNOPSIS
56 .In sys/types.h
57 .In sys/systm.h
58 .Pp
59 .Bd -literal
60 typedef void timeout_t (void *);
61 .Ed
62 .Ft struct callout_handle
63 .Fn timeout "timeout_t *func" "void *arg" "int ticks"
64 .Ft void
65 .Fn callout_handle_init "struct callout_handle *handle"
66 .Pp
67 .Bd -literal
68 struct callout_handle handle = CALLOUT_HANDLE_INITIALIZER(&handle)
69 .Ed
70 .Ft void
71 .Fn untimeout "timeout_t *func" "void *arg" "struct callout_handle handle"
72 .Ft void
73 .Fn callout_init "struct callout *c" "int mpsafe"
74 .Ft void
75 .Fn callout_init_mtx "struct callout *c" "struct mtx *mtx" "int flags"
76 .Ft int
77 .Fn callout_stop "struct callout *c"
78 .Ft int
79 .Fn callout_drain "struct callout *c"
80 .Ft int
81 .Fn callout_reset "struct callout *c" "int ticks" "timeout_t *func" "void *arg"
82 .Ft int
83 .Fn callout_pending "struct callout *c"
84 .Ft int
85 .Fn callout_active "struct callout *c"
86 .Fn callout_deactivate "struct callout *c"
87 .Sh DESCRIPTION
88 The function
89 .Fn timeout
90 schedules a call to the function given by the argument
91 .Fa func
92 to take place after
93 .Fa ticks Ns No /hz
94 seconds.
95 Non-positive values of
96 .Fa ticks
97 are silently converted to the value
98 .Sq 1 .
99 .Fa func
100 should be a pointer to a function that takes a
101 .Fa void *
102 argument.
103 Upon invocation,
104 .Fa func
105 will receive
106 .Fa arg
107 as its only argument.
108 The return value from
109 .Fn timeout
110 is a
111 .Ft struct callout_handle
112 which can be used in conjunction with the
113 .Fn untimeout
114 function to request that a scheduled timeout be canceled.
115 The
116 .Fn timeout
117 call is the old style and new code should use the
118 .Fn callout_*
119 functions.
120 .Pp
121 The function
122 .Fn callout_handle_init
123 can be used to initialize a handle to a state which will cause
124 any calls to untimeout with that handle to return with no side
125 effects.
126 .Pp
127 Assigning a callout handle the value of
128 .Fn CALLOUT_HANDLE_INITIALIZER
129 performs the same function as
130 .Fn callout_handle_init
131 and is provided for use on statically declared or global callout handles.
132 .Pp
133 The function
134 .Fn untimeout
135 cancels the timeout associated with
136 .Fa handle
137 using the
138 .Fa func
139 and
140 .Fa arg
141 arguments to validate the handle.
142 If the handle does not correspond to a timeout with
143 the function
144 .Fa func
145 taking the argument
146 .Fa arg
147 no action is taken.
148 .Fa handle
149 must be initialized by a previous call to
150 .Fn timeout ,
151 .Fn callout_handle_init ,
152 or assigned the value of
153 .Fn CALLOUT_HANDLE_INITIALIZER "&handle"
154 before being passed to
155 .Fn untimeout .
156 The behavior of calling untimeout without a previously initialized handle
157 is undefined.
158 The
159 .Fn untimeout
160 call is the old style and new code should use the
161 .Fn callout_*
162 functions.
163 .Pp
164 As handles are recycled by the system, it is possible (although unlikely)
165 that a handle from one invocation of
166 .Fn timeout
167 may match the handle of another invocation of
168 .Fn timeout
169 if both calls used the same function pointer and argument, and the first
170 timeout is expired or canceled before the second call.
171 The timeout facility offers O(1) running time for
172 .Fn timeout
173 and
174 .Fn untimeout .
175 Timeouts are executed from
176 .Fn softclock
177 with the
178 .Va Giant
179 lock held.
180 Thus they are protected from re-entrancy.
181 .Pp
182 The functions
183 .Fn callout_init ,
184 .Fn callout_init_mtx ,
185 .Fn callout_stop ,
186 .Fn callout_drain
187 and
188 .Fn callout_reset
189 are low-level routines for clients who wish to allocate their own
190 callout structures.
191 .Pp
192 The function
193 .Fn callout_init
194 initializes a callout so it can be passed to
195 .Fn callout_stop ,
196 .Fn callout_drain
197 or
198 .Fn callout_reset
199 without any side effects.
200 If the
201 .Fa mpsafe
202 argument is zero,
203 the callout structure is not considered to be
204 .Dq multi-processor safe ;
205 that is,
206 the Giant lock will be acquired before calling the callout function,
207 and released when the callout function returns.
208 .Pp
209 The
210 .Fn callout_init_mtx
211 function may be used as an alternative to
212 .Fn callout_init .
213 The parameter
214 .Fa mtx
215 specifies a mutex that is to be acquired by the callout subsystem
216 before calling the callout function, and released when the callout
217 function returns.
218 The following
219 .Fa flags
220 may be specified:
221 .Bl -tag -width ".Dv CALLOUT_RETURNUNLOCKED"
222 .It Dv CALLOUT_RETURNUNLOCKED
223 The callout function will release
224 .Fa mtx
225 itself, so the callout subsystem should not attempt to unlock it
226 after the callout function returns.
227 .El
228 .Pp
229 The function
230 .Fn callout_stop
231 cancels a callout if it is currently pending.
232 If the callout is pending, then
233 .Fn callout_stop
234 will return a non-zero value.
235 If the callout is not set, has already been serviced or is currently
236 being serviced, then zero will be returned.
237 If the callout has an associated mutex, then that mutex must be
238 held when this function is called.
239 .Pp
240 The function
241 .Fn callout_drain
242 is identical to
243 .Fn callout_stop
244 except that it will wait for the callout to be completed if it is
245 already in progress.
246 This function MUST NOT be called while holding any
247 locks on which the callout might block, or deadlock will result.
248 Note that if the callout subsystem has already begun processing this
249 callout, then the callout function may be invoked during the execution of
250 .Fn callout_drain .
251 However, the callout subsystem does guarantee that the callout will be
252 fully stopped before
253 .Fn callout_drain
254 returns.
255 .Pp
256 The function
257 .Fn callout_reset
258 first performs the equivalent of
259 .Fn callout_stop
260 to disestablish the callout, and then establishes a new callout in the
261 same manner as
262 .Fn timeout .
263 If there was already a pending callout and it was rescheduled, then
264 .Fn callout_reset
265 will return a non-zero value.
266 If the callout has an associated mutex, then that mutex must be
267 held when this function is called.
268 .Pp
269 The macros
270 .Fn callout_pending ,
271 .Fn callout_active
272 and
273 .Fn callout_deactivate
274 provide access to the current state of the callout.
275 Careful use of these macros can avoid many of the race conditions
276 that are inherent in asynchronous timer facilities; see
277 .Sx "Avoiding Race Conditions"
278 below for further details.
279 The
280 .Fn callout_pending
281 macro checks whether a callout is
282 .Em pending ;
283 a callout is considered
284 .Em pending
285 when a timeout has been set but the time has not yet arrived.
286 Note that once the timeout time arrives and the callout subsystem
287 starts to process this callout,
288 .Fn callout_pending
289 will return
290 .Dv FALSE
291 even though the callout function may not have finished (or even begun)
292 executing.
293 The
294 .Fn callout_active
295 macro checks whether a callout is marked as
296 .Em active ,
297 and the
298 .Fn callout_deactivate
299 macro clears the callout's
300 .Em active
301 flag.
302 The callout subsystem marks a callout as
303 .Em active
304 when a timeout is set and it clears the
305 .Em active
306 flag in
307 .Fn callout_stop
308 and
309 .Fn callout_drain ,
310 but it
311 .Em does not
312 clear it when a callout expires normally via the execution of the
313 callout function.
314 .Ss "Avoiding Race Conditions"
315 The callout subsystem invokes callout functions from its own timer
316 context.
317 Without some kind of synchronization it is possible that a callout
318 function will be invoked concurrently with an attempt to stop or reset
319 the callout by another thread.
320 In particular, since callout functions typically acquire a mutex as
321 their first action, the callout function may have already been invoked,
322 but be blocked waiting for that mutex at the time that another thread
323 tries to reset or stop the callout.
324 .Pp
325 The callout subsystem provides a number of mechanisms to address these
326 synchronization concerns:
327 .Bl -enum -offset indent
328 .It
329 If the callout has an associated mutex that was specified using the
330 .Fn callout_init_mtx
331 function (or implicitly specified as the
332 .Va Giant
333 mutex using
334 .Fn callout_init
335 with
336 .Fa mpsafe
337 set to
338 .Dv FALSE ) ,
339 then this mutex is used to avoid the race conditions.
340 The associated mutex must be acquired by the caller before calling
341 .Fn callout_stop
342 or
343 .Fn callout_reset
344 and it is guaranteed that the callout will be correctly stopped
345 or reset as expected.
346 Note that it is still necessary to use
347 .Fn callout_drain
348 before destroying the callout or its associated mutex.
349 .It
350 The return value from
351 .Fn callout_stop
352 and
353 .Fn callout_reset
354 indicates whether or not the callout was removed.
355 If it is known that the callout was set and the callout function has
356 not yet executed, then a return value of
357 .Dv FALSE
358 indicates that the callout function is about to be called.
359 For example:
360 .Bd -literal -offset indent
361 if (sc->sc_flags & SCFLG_CALLOUT_RUNNING) {
362         if (callout_stop(&sc->sc_callout)) {
363                 sc->sc_flags &= ~SCFLG_CALLOUT_RUNNING;
364                 /* successfully stopped */
365         } else {
366                 /*
367                  * callout has expired and callout
368                  * function is about to be executed
369                  */
370         }
371 }
372 .Ed
373 .Pp
374 .It
375 The
376 .Fn callout_pending ,
377 .Fn callout_active
378 and
379 .Fn callout_deactivate
380 macros can be used together to work around the race conditions.
381 When a callout's timeout is set, the callout subsystem marks the
382 callout as both
383 .Em active
384 and
385 .Em pending .
386 When the timeout time arrives, the callout subsystem begins processing
387 the callout by first clearing the
388 .Em pending
389 flag.
390 It then invokes the callout function without changing the
391 .Em active
392 flag, and does not clear the
393 .Em active
394 flag even after the callout function returns.
395 The mechanism described here requires the callout function itself to
396 clear the
397 .Em active
398 flag using the
399 .Fn callout_deactivate
400 macro.
401 The
402 .Fn callout_stop
403 and
404 .Fn callout_drain
405 functions always clear both the
406 .Em active
407 and
408 .Em pending
409 flags before returning.
410 .Pp
411 The callout function should first check the
412 .Em pending
413 flag and return without action if
414 .Fn callout_pending
415 returns
416 .Dv TRUE .
417 This indicates that the callout was rescheduled using
418 .Fn callout_reset
419 just before the callout function was invoked.
420 If
421 .Fn callout_active
422 returns
423 .Dv FALSE
424 then the callout function should also return without action.
425 This indicates that the callout has been stopped.
426 Finally, the callout function should call
427 .Fn callout_deactivate
428 to clear the
429 .Em active
430 flag.
431 For example:
432 .Bd -literal -offset indent
433 mtx_lock(&sc->sc_mtx);
434 if (callout_pending(&sc->sc_callout)) {
435         /* callout was reset */
436         mtx_unlock(&sc->sc_mtx);
437         return;
438 }
439 if (!callout_active(&sc->sc_callout)) {
440         /* callout was stopped */
441         mtx_unlock(&sc->sc_mtx);
442         return;
443 }
444 callout_deactivate(&sc->sc_callout);
445 /* rest of callout function */
446 .Ed
447 .Pp
448 Together with appropriate synchronization, such as the mutex used above,
449 this approach permits the
450 .Fn callout_stop
451 and
452 .Fn callout_reset
453 functions to be used at any time without races.
454 For example:
455 .Bd -literal -offset indent
456 mtx_lock(&sc->sc_mtx);
457 callout_stop(&sc->sc_callout);
458 /* The callout is effectively stopped now. */
459 .Ed
460 .Pp
461 If the callout is still pending then these functions operate normally,
462 but if processing of the callout has already begun then the tests in
463 the callout function cause it to return without further action.
464 Synchronization between the callout function and other code ensures that
465 stopping or resetting the callout will never be attempted while the
466 callout function is past the
467 .Fn callout_deactivate
468 call.
469 .Pp
470 The above technique additionally ensures that the
471 .Em active
472 flag always reflects whether the callout is effectively enabled or
473 disabled.
474 If
475 .Fn callout_active
476 returns false, then the callout is effectively disabled, since even if
477 the callout subsystem is actually just about to invoke the callout
478 function, the callout function will return without action.
479 .El
480 .Pp
481 There is one final race condition that must be considered when a
482 callout is being stopped for the last time.
483 In this case it may not be safe to let the callout function itself
484 detect that the callout was stopped, since it may need to access
485 data objects that have already been destroyed or recycled.
486 To ensure that the callout is completely finished, a call to
487 .Fn callout_drain
488 should be used.
489 .Sh RETURN VALUES
490 The
491 .Fn timeout
492 function returns a
493 .Ft struct callout_handle
494 that can be passed to
495 .Fn untimeout .
496 The
497 .Fn callout_stop
498 and
499 .Fn callout_drain
500 functions return non-zero if the callout was still pending when it was
501 called or zero otherwise.
502 .Sh HISTORY
503 The current timeout and untimeout routines are based on the work of
504 .An Adam M. Costello
505 and
506 .An George Varghese ,
507 published in a technical report entitled
508 .%T "Redesigning the BSD Callout and Timer Facilities"
509 and modified slightly for inclusion in
510 .Fx
511 by
512 .An Justin T. Gibbs .
513 The original work on the data structures used in this implementation
514 was published by
515 .An G. Varghese
516 and
517 .An A. Lauck
518 in the paper
519 .%T "Hashed and Hierarchical Timing Wheels: Data Structures for the Efficient Implementation of a Timer Facility"
520 in the
521 .%B "Proceedings of the 11th ACM Annual Symposium on Operating Systems Principles" .
522 The current implementation replaces the long standing
523 .Bx
524 linked list
525 callout mechanism which offered O(n) insertion and removal running time
526 but did not generate or require handles for untimeout operations.