]> CyberLeo.Net >> Repos - FreeBSD/releng/7.2.git/blob - share/man/man9/timeout.9
Create releng/7.2 from stable/7 in preparation for 7.2-RELEASE.
[FreeBSD/releng/7.2.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
125 .Fn untimeout
126 with that handle to return with no side
127 effects.
128 .Pp
129 Assigning a callout handle the value of
130 .Fn CALLOUT_HANDLE_INITIALIZER
131 performs the same function as
132 .Fn callout_handle_init
133 and is provided for use on statically declared or global callout handles.
134 .Pp
135 The function
136 .Fn untimeout
137 cancels the timeout associated with
138 .Fa handle
139 using the
140 .Fa func
141 and
142 .Fa arg
143 arguments to validate the handle.
144 If the handle does not correspond to a timeout with
145 the function
146 .Fa func
147 taking the argument
148 .Fa arg
149 no action is taken.
150 .Fa handle
151 must be initialized by a previous call to
152 .Fn timeout ,
153 .Fn callout_handle_init ,
154 or assigned the value of
155 .Fn CALLOUT_HANDLE_INITIALIZER "&handle"
156 before being passed to
157 .Fn untimeout .
158 The behavior of calling
159 .Fn untimeout
160 with an uninitialized handle
161 is undefined.
162 The
163 .Fn untimeout
164 call is the old style and new code should use the
165 .Fn callout_*
166 functions.
167 .Pp
168 As handles are recycled by the system, it is possible (although unlikely)
169 that a handle from one invocation of
170 .Fn timeout
171 may match the handle of another invocation of
172 .Fn timeout
173 if both calls used the same function pointer and argument, and the first
174 timeout is expired or canceled before the second call.
175 The timeout facility offers O(1) running time for
176 .Fn timeout
177 and
178 .Fn untimeout .
179 Timeouts are executed from
180 .Fn softclock
181 with the
182 .Va Giant
183 lock held.
184 Thus they are protected from re-entrancy.
185 .Pp
186 The functions
187 .Fn callout_init ,
188 .Fn callout_init_mtx ,
189 .Fn callout_stop ,
190 .Fn callout_drain
191 and
192 .Fn callout_reset
193 are low-level routines for clients who wish to allocate their own
194 callout structures.
195 .Pp
196 The function
197 .Fn callout_init
198 initializes a callout so it can be passed to
199 .Fn callout_stop ,
200 .Fn callout_drain
201 or
202 .Fn callout_reset
203 without any side effects.
204 If the
205 .Fa mpsafe
206 argument is zero,
207 the callout structure is not considered to be
208 .Dq multi-processor safe ;
209 that is,
210 the Giant lock will be acquired before calling the callout function,
211 and released when the callout function returns.
212 .Pp
213 The
214 .Fn callout_init_mtx
215 function may be used as an alternative to
216 .Fn callout_init .
217 The parameter
218 .Fa mtx
219 specifies a mutex that is to be acquired by the callout subsystem
220 before calling the callout function, and released when the callout
221 function returns.
222 The following
223 .Fa flags
224 may be specified:
225 .Bl -tag -width ".Dv CALLOUT_RETURNUNLOCKED"
226 .It Dv CALLOUT_RETURNUNLOCKED
227 The callout function will release
228 .Fa mtx
229 itself, so the callout subsystem should not attempt to unlock it
230 after the callout function returns.
231 .El
232 .Pp
233 The function
234 .Fn callout_stop
235 cancels a callout if it is currently pending.
236 If the callout is pending, then
237 .Fn callout_stop
238 will return a non-zero value.
239 If the callout is not set, has already been serviced or is currently
240 being serviced, then zero will be returned.
241 If the callout has an associated mutex, then that mutex must be
242 held when this function is called.
243 .Pp
244 The function
245 .Fn callout_drain
246 is identical to
247 .Fn callout_stop
248 except that it will wait for the callout to be completed if it is
249 already in progress.
250 This function MUST NOT be called while holding any
251 locks on which the callout might block, or deadlock will result.
252 Note that if the callout subsystem has already begun processing this
253 callout, then the callout function may be invoked during the execution of
254 .Fn callout_drain .
255 However, the callout subsystem does guarantee that the callout will be
256 fully stopped before
257 .Fn callout_drain
258 returns.
259 .Pp
260 The function
261 .Fn callout_reset
262 first performs the equivalent of
263 .Fn callout_stop
264 to disestablish the callout, and then establishes a new callout in the
265 same manner as
266 .Fn timeout .
267 If there was already a pending callout and it was rescheduled, then
268 .Fn callout_reset
269 will return a non-zero value.
270 If the callout has an associated mutex, then that mutex must be
271 held when this function is called.
272 .Pp
273 The macros
274 .Fn callout_pending ,
275 .Fn callout_active
276 and
277 .Fn callout_deactivate
278 provide access to the current state of the callout.
279 Careful use of these macros can avoid many of the race conditions
280 that are inherent in asynchronous timer facilities; see
281 .Sx "Avoiding Race Conditions"
282 below for further details.
283 The
284 .Fn callout_pending
285 macro checks whether a callout is
286 .Em pending ;
287 a callout is considered
288 .Em pending
289 when a timeout has been set but the time has not yet arrived.
290 Note that once the timeout time arrives and the callout subsystem
291 starts to process this callout,
292 .Fn callout_pending
293 will return
294 .Dv FALSE
295 even though the callout function may not have finished (or even begun)
296 executing.
297 The
298 .Fn callout_active
299 macro checks whether a callout is marked as
300 .Em active ,
301 and the
302 .Fn callout_deactivate
303 macro clears the callout's
304 .Em active
305 flag.
306 The callout subsystem marks a callout as
307 .Em active
308 when a timeout is set and it clears the
309 .Em active
310 flag in
311 .Fn callout_stop
312 and
313 .Fn callout_drain ,
314 but it
315 .Em does not
316 clear it when a callout expires normally via the execution of the
317 callout function.
318 .Ss "Avoiding Race Conditions"
319 The callout subsystem invokes callout functions from its own timer
320 context.
321 Without some kind of synchronization it is possible that a callout
322 function will be invoked concurrently with an attempt to stop or reset
323 the callout by another thread.
324 In particular, since callout functions typically acquire a mutex as
325 their first action, the callout function may have already been invoked,
326 but be blocked waiting for that mutex at the time that another thread
327 tries to reset or stop the callout.
328 .Pp
329 The callout subsystem provides a number of mechanisms to address these
330 synchronization concerns:
331 .Bl -enum -offset indent
332 .It
333 If the callout has an associated mutex that was specified using the
334 .Fn callout_init_mtx
335 function (or implicitly specified as the
336 .Va Giant
337 mutex using
338 .Fn callout_init
339 with
340 .Fa mpsafe
341 set to
342 .Dv FALSE ) ,
343 then this mutex is used to avoid the race conditions.
344 The associated mutex must be acquired by the caller before calling
345 .Fn callout_stop
346 or
347 .Fn callout_reset
348 and it is guaranteed that the callout will be correctly stopped
349 or reset as expected.
350 Note that it is still necessary to use
351 .Fn callout_drain
352 before destroying the callout or its associated mutex.
353 .It
354 The return value from
355 .Fn callout_stop
356 and
357 .Fn callout_reset
358 indicates whether or not the callout was removed.
359 If it is known that the callout was set and the callout function has
360 not yet executed, then a return value of
361 .Dv FALSE
362 indicates that the callout function is about to be called.
363 For example:
364 .Bd -literal -offset indent
365 if (sc->sc_flags & SCFLG_CALLOUT_RUNNING) {
366         if (callout_stop(&sc->sc_callout)) {
367                 sc->sc_flags &= ~SCFLG_CALLOUT_RUNNING;
368                 /* successfully stopped */
369         } else {
370                 /*
371                  * callout has expired and callout
372                  * function is about to be executed
373                  */
374         }
375 }
376 .Ed
377 .It
378 The
379 .Fn callout_pending ,
380 .Fn callout_active
381 and
382 .Fn callout_deactivate
383 macros can be used together to work around the race conditions.
384 When a callout's timeout is set, the callout subsystem marks the
385 callout as both
386 .Em active
387 and
388 .Em pending .
389 When the timeout time arrives, the callout subsystem begins processing
390 the callout by first clearing the
391 .Em pending
392 flag.
393 It then invokes the callout function without changing the
394 .Em active
395 flag, and does not clear the
396 .Em active
397 flag even after the callout function returns.
398 The mechanism described here requires the callout function itself to
399 clear the
400 .Em active
401 flag using the
402 .Fn callout_deactivate
403 macro.
404 The
405 .Fn callout_stop
406 and
407 .Fn callout_drain
408 functions always clear both the
409 .Em active
410 and
411 .Em pending
412 flags before returning.
413 .Pp
414 The callout function should first check the
415 .Em pending
416 flag and return without action if
417 .Fn callout_pending
418 returns
419 .Dv TRUE .
420 This indicates that the callout was rescheduled using
421 .Fn callout_reset
422 just before the callout function was invoked.
423 If
424 .Fn callout_active
425 returns
426 .Dv FALSE
427 then the callout function should also return without action.
428 This indicates that the callout has been stopped.
429 Finally, the callout function should call
430 .Fn callout_deactivate
431 to clear the
432 .Em active
433 flag.
434 For example:
435 .Bd -literal -offset indent
436 mtx_lock(&sc->sc_mtx);
437 if (callout_pending(&sc->sc_callout)) {
438         /* callout was reset */
439         mtx_unlock(&sc->sc_mtx);
440         return;
441 }
442 if (!callout_active(&sc->sc_callout)) {
443         /* callout was stopped */
444         mtx_unlock(&sc->sc_mtx);
445         return;
446 }
447 callout_deactivate(&sc->sc_callout);
448 /* rest of callout function */
449 .Ed
450 .Pp
451 Together with appropriate synchronization, such as the mutex used above,
452 this approach permits the
453 .Fn callout_stop
454 and
455 .Fn callout_reset
456 functions to be used at any time without races.
457 For example:
458 .Bd -literal -offset indent
459 mtx_lock(&sc->sc_mtx);
460 callout_stop(&sc->sc_callout);
461 /* The callout is effectively stopped now. */
462 .Ed
463 .Pp
464 If the callout is still pending then these functions operate normally,
465 but if processing of the callout has already begun then the tests in
466 the callout function cause it to return without further action.
467 Synchronization between the callout function and other code ensures that
468 stopping or resetting the callout will never be attempted while the
469 callout function is past the
470 .Fn callout_deactivate
471 call.
472 .Pp
473 The above technique additionally ensures that the
474 .Em active
475 flag always reflects whether the callout is effectively enabled or
476 disabled.
477 If
478 .Fn callout_active
479 returns false, then the callout is effectively disabled, since even if
480 the callout subsystem is actually just about to invoke the callout
481 function, the callout function will return without action.
482 .El
483 .Pp
484 There is one final race condition that must be considered when a
485 callout is being stopped for the last time.
486 In this case it may not be safe to let the callout function itself
487 detect that the callout was stopped, since it may need to access
488 data objects that have already been destroyed or recycled.
489 To ensure that the callout is completely finished, a call to
490 .Fn callout_drain
491 should be used.
492 .Sh RETURN VALUES
493 The
494 .Fn timeout
495 function returns a
496 .Ft struct callout_handle
497 that can be passed to
498 .Fn untimeout .
499 The
500 .Fn callout_stop
501 and
502 .Fn callout_drain
503 functions return non-zero if the callout was still pending when it was
504 called or zero otherwise.
505 .Sh HISTORY
506 The current timeout and untimeout routines are based on the work of
507 .An Adam M. Costello
508 and
509 .An George Varghese ,
510 published in a technical report entitled
511 .%T "Redesigning the BSD Callout and Timer Facilities"
512 and modified slightly for inclusion in
513 .Fx
514 by
515 .An Justin T. Gibbs .
516 The original work on the data structures used in this implementation
517 was published by
518 .An G. Varghese
519 and
520 .An A. Lauck
521 in the paper
522 .%T "Hashed and Hierarchical Timing Wheels: Data Structures for the Efficient Implementation of a Timer Facility"
523 in the
524 .%B "Proceedings of the 11th ACM Annual Symposium on Operating Systems Principles" .
525 The current implementation replaces the long standing
526 .Bx
527 linked list
528 callout mechanism which offered O(n) insertion and removal running time
529 but did not generate or require handles for untimeout operations.