]> CyberLeo.Net >> Repos - FreeBSD/FreeBSD.git/blob - share/man/man9/timeout.9
IFC @r271694
[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 .\"
18 .\" THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
19 .\" ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
20 .\" TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
21 .\" PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE
22 .\" LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
23 .\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
24 .\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
25 .\" INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
26 .\" CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
27 .\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
28 .\" POSSIBILITY OF SUCH DAMAGE.
29 .\"
30 .\" $FreeBSD$
31 .\"
32 .Dd August 21, 2014
33 .Dt TIMEOUT 9
34 .Os
35 .Sh NAME
36 .Nm timeout ,
37 .Nm untimeout ,
38 .Nm callout_handle_init ,
39 .Nm callout_init ,
40 .Nm callout_init_mtx ,
41 .Nm callout_init_rm ,
42 .Nm callout_init_rw ,
43 .Nm callout_stop ,
44 .Nm callout_drain ,
45 .Nm callout_reset ,
46 .Nm callout_reset_on ,
47 .Nm callout_reset_curcpu ,
48 .Nm callout_reset_sbt ,
49 .Nm callout_reset_sbt_on ,
50 .Nm callout_reset_sbt_curcpu ,
51 .Nm callout_schedule ,
52 .Nm callout_schedule_on ,
53 .Nm callout_schedule_curcpu ,
54 .Nm callout_pending ,
55 .Nm callout_active ,
56 .Nm callout_deactivate
57 .Nd execute a function after a specified length of time
58 .Sh SYNOPSIS
59 .In sys/types.h
60 .In sys/systm.h
61 .Bd -literal
62 typedef void timeout_t (void *);
63 .Ed
64 .Ft struct callout_handle
65 .Fn timeout "timeout_t *func" "void *arg" "int ticks"
66 .Ft void
67 .Fn callout_handle_init "struct callout_handle *handle"
68 .Bd -literal
69 struct callout_handle handle = CALLOUT_HANDLE_INITIALIZER(&handle);
70 .Ed
71 .Ft void
72 .Fn untimeout "timeout_t *func" "void *arg" "struct callout_handle handle"
73 .Ft void
74 .Fn callout_init "struct callout *c" "int mpsafe"
75 .Ft void
76 .Fn callout_init_mtx "struct callout *c" "struct mtx *mtx" "int flags"
77 .Ft void
78 .Fn callout_init_rm "struct callout *c" "struct rmlock *rm" "int flags"
79 .Ft void
80 .Fn callout_init_rw "struct callout *c" "struct rwlock *rw" "int flags"
81 .Ft int
82 .Fn callout_stop "struct callout *c"
83 .Ft int
84 .Fn callout_drain "struct callout *c"
85 .Ft int
86 .Fn callout_reset "struct callout *c" "int ticks" "timeout_t *func" "void *arg"
87 .Ft int
88 .Fn callout_reset_on "struct callout *c" "int ticks" "timeout_t *func" \
89 "void *arg" "int cpu"
90 .Ft int
91 .Fn callout_reset_sbt_on "struct callout *c" "sbintime_t sbt" \
92 "sbintime_t pr" "timeout_t *func" "void *arg" "int cpu" "int flags"
93 .Ft int
94 .Fn callout_reset_curcpu "struct callout *c" "int ticks" "timeout_t *func" \
95 "void *arg"
96 .Ft int
97 .Fn callout_schedule "struct callout *c" "int ticks"
98 .Ft int
99 .Fn callout_schedule_on "struct callout *c" "int ticks" "int cpu"
100 .Ft int
101 .Fn callout_schedule_curcpu "struct callout *c" "int ticks"
102 .Ft int
103 .Fn callout_pending "struct callout *c"
104 .Ft int
105 .Fn callout_active "struct callout *c"
106 .Ft void
107 .Fn callout_deactivate "struct callout *c"
108 .Sh DESCRIPTION
109 The function
110 .Fn timeout
111 schedules a call to the function given by the argument
112 .Fa func
113 to take place after
114 .Fa ticks Ns No /hz
115 seconds.
116 Non-positive values of
117 .Fa ticks
118 are silently converted to the value
119 .Sq 1 .
120 .Fa func
121 should be a pointer to a function that takes a
122 .Fa void *
123 argument.
124 Upon invocation,
125 .Fa func
126 will receive
127 .Fa arg
128 as its only argument.
129 The return value from
130 .Fn timeout
131 is a
132 .Ft struct callout_handle
133 which can be used in conjunction with the
134 .Fn untimeout
135 function to request that a scheduled timeout be canceled.
136 The
137 .Fn timeout
138 call is the old style and new code should use the
139 .Fn callout_*
140 functions.
141 .Pp
142 The function
143 .Fn callout_handle_init
144 can be used to initialize a handle to a state which will cause
145 any calls to
146 .Fn untimeout
147 with that handle to return with no side
148 effects.
149 .Pp
150 Assigning a callout handle the value of
151 .Fn CALLOUT_HANDLE_INITIALIZER
152 performs the same function as
153 .Fn callout_handle_init
154 and is provided for use on statically declared or global callout handles.
155 .Pp
156 The function
157 .Fn untimeout
158 cancels the timeout associated with
159 .Fa handle
160 using the
161 .Fa func
162 and
163 .Fa arg
164 arguments to validate the handle.
165 If the handle does not correspond to a timeout with
166 the function
167 .Fa func
168 taking the argument
169 .Fa arg
170 no action is taken.
171 .Fa handle
172 must be initialized by a previous call to
173 .Fn timeout ,
174 .Fn callout_handle_init ,
175 or assigned the value of
176 .Fn CALLOUT_HANDLE_INITIALIZER "&handle"
177 before being passed to
178 .Fn untimeout .
179 The behavior of calling
180 .Fn untimeout
181 with an uninitialized handle
182 is undefined.
183 The
184 .Fn untimeout
185 call is the old style and new code should use the
186 .Fn callout_*
187 functions.
188 .Pp
189 As handles are recycled by the system, it is possible (although unlikely)
190 that a handle from one invocation of
191 .Fn timeout
192 may match the handle of another invocation of
193 .Fn timeout
194 if both calls used the same function pointer and argument, and the first
195 timeout is expired or canceled before the second call.
196 The timeout facility offers O(1) running time for
197 .Fn timeout
198 and
199 .Fn untimeout .
200 Timeouts are executed from
201 .Fn softclock
202 with the
203 .Va Giant
204 lock held.
205 Thus they are protected from re-entrancy.
206 .Pp
207 The functions
208 .Fn callout_init ,
209 .Fn callout_init_mtx ,
210 .Fn callout_init_rm ,
211 .Fn callout_init_rw ,
212 .Fn callout_stop ,
213 .Fn callout_drain ,
214 .Fn callout_reset
215 and
216 .Fn callout_schedule
217 are low-level routines for clients who wish to allocate their own
218 callout structures.
219 .Pp
220 The function
221 .Fn callout_init
222 initializes a callout so it can be passed to
223 .Fn callout_stop ,
224 .Fn callout_drain ,
225 .Fn callout_reset
226 or
227 .Fn callout_schedule
228 without any side effects.
229 If the
230 .Fa mpsafe
231 argument is zero,
232 the callout structure is not considered to be
233 .Dq multi-processor safe ;
234 that is,
235 the Giant lock will be acquired before calling the callout function,
236 and released when the callout function returns.
237 .Pp
238 The
239 .Fn callout_init_mtx
240 function may be used as an alternative to
241 .Fn callout_init .
242 The parameter
243 .Fa mtx
244 specifies a mutex that is to be acquired by the callout subsystem
245 before calling the callout function, and released when the callout
246 function returns.
247 The following
248 .Fa flags
249 may be specified:
250 .Bl -tag -width ".Dv CALLOUT_RETURNUNLOCKED"
251 .It Dv CALLOUT_RETURNUNLOCKED
252 The callout function will release
253 .Fa mtx
254 itself, so the callout subsystem should not attempt to unlock it
255 after the callout function returns.
256 .El
257 .Pp
258 The
259 .Fn callout_init_rw
260 and the
261 .Fn callout_init_rm
262 fuctions serve the need of using rwlocks and rmlocks in conjunction
263 with callouts.
264 The functions do the same as
265 .Fn callout_init
266 with the possibility of specifying an extra
267 .Fa rw
268 or
269 .Fa rm
270 argument.
271 If an
272 .Fa rm
273 argument is specified, the lock should be created without passing the
274 .Dv RM_SLEEPABLE
275 flag.
276 The usable lock classes are currently limited to mutexes, rwlocks and
277 non-sleepable rmlocks, because callout handlers run in softclock swi,
278 so they cannot sleep nor acquire sleepable locks like sx or lockmgr.
279 The following
280 .Fa flags
281 may be specified:
282 .Bl -tag -width ".Dv CALLOUT_SHAREDLOCK"
283 .It Dv CALLOUT_SHAREDLOCK
284 The lock is only acquired in read mode when running the callout handler.
285 It has no effects when used in conjunction with
286 .Fa mtx .
287 .El
288 .Pp
289 The function
290 .Fn callout_stop
291 cancels a callout if it is currently pending.
292 If the callout is pending, then
293 .Fn callout_stop
294 will return a non-zero value.
295 If the callout is not set, has already been serviced or is currently
296 being serviced, then zero will be returned.
297 If the callout has an associated mutex, then that mutex must be
298 held when this function is called.
299 .Pp
300 The function
301 .Fn callout_drain
302 is identical to
303 .Fn callout_stop
304 except that it will wait for the callout to be completed if it is
305 already in progress.
306 This function MUST NOT be called while holding any
307 locks on which the callout might block, or deadlock will result.
308 Note that if the callout subsystem has already begun processing this
309 callout, then the callout function may be invoked during the execution of
310 .Fn callout_drain .
311 However, the callout subsystem does guarantee that the callout will be
312 fully stopped before
313 .Fn callout_drain
314 returns.
315 .Pp
316 The function
317 .Fn callout_reset
318 first performs the equivalent of
319 .Fn callout_stop
320 to disestablish the callout, and then establishes a new callout in the
321 same manner as
322 .Fn timeout .
323 If there was already a pending callout and it was rescheduled, then
324 .Fn callout_reset
325 will return a non-zero value.
326 If the callout has an associated mutex, then that mutex must be
327 held when this function is called.
328 The function
329 .Fn callout_schedule
330 (re)schedules an existing callout for a new period of time;
331 it is equivalent to calling
332 .Fn callout_reset
333 with the
334 .Fa func
335 and
336 .Fa arg
337 parameters extracted from the callout structure (though possibly with
338 lower overhead).
339 .Pp
340 The functions
341 .Fn callout_reset_on
342 and
343 .Fn callout_schedule_on
344 are equivalent to
345 .Fn callout_reset
346 and
347 .Fn callout_schedule
348 but take an extra parameter specifying the target CPU for the callout.
349 .Pp
350 The function
351 .Fn callout_reset_sbt_on
352 allows to get higher time resolution, taking relative or absolute time
353 and precision instead of relative ticks count.
354 If specified time is in past, it will be silently converted to present
355 to run handler as soon as possible.
356 .Pp
357 The following
358 .Fa flags
359 may be specified:
360 .Bl -tag -width ".Dv C_DIRECT_EXEC"
361 .It Dv C_ABSOLUTE
362 Handle the
363 .Fa sbt
364 argument as absolute time of the event since boot, or relative time otherwise.
365 .It Dv C_DIRECT_EXEC
366 Run handler directly from hardware interrupt context instead of softclock swi.
367 It is faster, but puts more constraints on handlers.
368 Handlers may use only spin mutexes for locking, and they must be fast because
369 they run with absolute priority.
370 .It Fn C_PREL
371 Specifies relative event time precision as binary logarithm of time interval
372 divided by acceptable time deviation: 1 -- 1/2, 2 -- 1/4, etc.
373 Smaller value allows to aggregate more events in one timer interrupt to
374 reduce processing overhead and power consumption.
375 .It Dv C_HARDCLOCK
376 Align the timeouts, if possible, to 
377 .Fn hardclock  
378 calls.
379 .El
380 .Pp
381 The functions
382 .Fn callout_reset_curcpu
383 and
384 .Fn callout_schedule_curcpu
385 are wrappers for
386 .Fn callout_reset_on
387 and
388 .Fn callout_schedule_on
389 using the current CPU as the target CPU.
390 .Pp
391 The macros
392 .Fn callout_pending ,
393 .Fn callout_active
394 and
395 .Fn callout_deactivate
396 provide access to the current state of the callout.
397 Careful use of these macros can avoid many of the race conditions
398 that are inherent in asynchronous timer facilities; see
399 .Sx "Avoiding Race Conditions"
400 below for further details.
401 The
402 .Fn callout_pending
403 macro checks whether a callout is
404 .Em pending ;
405 a callout is considered
406 .Em pending
407 when a timeout has been set but the time has not yet arrived.
408 Note that once the timeout time arrives and the callout subsystem
409 starts to process this callout,
410 .Fn callout_pending
411 will return
412 .Dv FALSE
413 even though the callout function may not have finished (or even begun)
414 executing.
415 The
416 .Fn callout_active
417 macro checks whether a callout is marked as
418 .Em active ,
419 and the
420 .Fn callout_deactivate
421 macro clears the callout's
422 .Em active
423 flag.
424 The callout subsystem marks a callout as
425 .Em active
426 when a timeout is set and it clears the
427 .Em active
428 flag in
429 .Fn callout_stop
430 and
431 .Fn callout_drain ,
432 but it
433 .Em does not
434 clear it when a callout expires normally via the execution of the
435 callout function.
436 .Ss "Avoiding Race Conditions"
437 The callout subsystem invokes callout functions from its own timer
438 context.
439 Without some kind of synchronization it is possible that a callout
440 function will be invoked concurrently with an attempt to stop or reset
441 the callout by another thread.
442 In particular, since callout functions typically acquire a mutex as
443 their first action, the callout function may have already been invoked,
444 but be blocked waiting for that mutex at the time that another thread
445 tries to reset or stop the callout.
446 .Pp
447 The callout subsystem provides a number of mechanisms to address these
448 synchronization concerns:
449 .Bl -enum -offset indent
450 .It
451 If the callout has an associated mutex that was specified using the
452 .Fn callout_init_mtx
453 function (or implicitly specified as the
454 .Va Giant
455 mutex using
456 .Fn callout_init
457 with
458 .Fa mpsafe
459 set to
460 .Dv FALSE ) ,
461 then this mutex is used to avoid the race conditions.
462 The associated mutex must be acquired by the caller before calling
463 .Fn callout_stop
464 or
465 .Fn callout_reset
466 and it is guaranteed that the callout will be correctly stopped
467 or reset as expected.
468 Note that it is still necessary to use
469 .Fn callout_drain
470 before destroying the callout or its associated mutex.
471 .It
472 The return value from
473 .Fn callout_stop
474 and
475 .Fn callout_reset
476 indicates whether or not the callout was removed.
477 If it is known that the callout was set and the callout function has
478 not yet executed, then a return value of
479 .Dv FALSE
480 indicates that the callout function is about to be called.
481 For example:
482 .Bd -literal -offset indent
483 if (sc->sc_flags & SCFLG_CALLOUT_RUNNING) {
484         if (callout_stop(&sc->sc_callout)) {
485                 sc->sc_flags &= ~SCFLG_CALLOUT_RUNNING;
486                 /* successfully stopped */
487         } else {
488                 /*
489                  * callout has expired and callout
490                  * function is about to be executed
491                  */
492         }
493 }
494 .Ed
495 .It
496 The
497 .Fn callout_pending ,
498 .Fn callout_active
499 and
500 .Fn callout_deactivate
501 macros can be used together to work around the race conditions.
502 When a callout's timeout is set, the callout subsystem marks the
503 callout as both
504 .Em active
505 and
506 .Em pending .
507 When the timeout time arrives, the callout subsystem begins processing
508 the callout by first clearing the
509 .Em pending
510 flag.
511 It then invokes the callout function without changing the
512 .Em active
513 flag, and does not clear the
514 .Em active
515 flag even after the callout function returns.
516 The mechanism described here requires the callout function itself to
517 clear the
518 .Em active
519 flag using the
520 .Fn callout_deactivate
521 macro.
522 The
523 .Fn callout_stop
524 and
525 .Fn callout_drain
526 functions always clear both the
527 .Em active
528 and
529 .Em pending
530 flags before returning.
531 .Pp
532 The callout function should first check the
533 .Em pending
534 flag and return without action if
535 .Fn callout_pending
536 returns
537 .Dv TRUE .
538 This indicates that the callout was rescheduled using
539 .Fn callout_reset
540 just before the callout function was invoked.
541 If
542 .Fn callout_active
543 returns
544 .Dv FALSE
545 then the callout function should also return without action.
546 This indicates that the callout has been stopped.
547 Finally, the callout function should call
548 .Fn callout_deactivate
549 to clear the
550 .Em active
551 flag.
552 For example:
553 .Bd -literal -offset indent
554 mtx_lock(&sc->sc_mtx);
555 if (callout_pending(&sc->sc_callout)) {
556         /* callout was reset */
557         mtx_unlock(&sc->sc_mtx);
558         return;
559 }
560 if (!callout_active(&sc->sc_callout)) {
561         /* callout was stopped */
562         mtx_unlock(&sc->sc_mtx);
563         return;
564 }
565 callout_deactivate(&sc->sc_callout);
566 /* rest of callout function */
567 .Ed
568 .Pp
569 Together with appropriate synchronization, such as the mutex used above,
570 this approach permits the
571 .Fn callout_stop
572 and
573 .Fn callout_reset
574 functions to be used at any time without races.
575 For example:
576 .Bd -literal -offset indent
577 mtx_lock(&sc->sc_mtx);
578 callout_stop(&sc->sc_callout);
579 /* The callout is effectively stopped now. */
580 .Ed
581 .Pp
582 If the callout is still pending then these functions operate normally,
583 but if processing of the callout has already begun then the tests in
584 the callout function cause it to return without further action.
585 Synchronization between the callout function and other code ensures that
586 stopping or resetting the callout will never be attempted while the
587 callout function is past the
588 .Fn callout_deactivate
589 call.
590 .Pp
591 The above technique additionally ensures that the
592 .Em active
593 flag always reflects whether the callout is effectively enabled or
594 disabled.
595 If
596 .Fn callout_active
597 returns false, then the callout is effectively disabled, since even if
598 the callout subsystem is actually just about to invoke the callout
599 function, the callout function will return without action.
600 .El
601 .Pp
602 There is one final race condition that must be considered when a
603 callout is being stopped for the last time.
604 In this case it may not be safe to let the callout function itself
605 detect that the callout was stopped, since it may need to access
606 data objects that have already been destroyed or recycled.
607 To ensure that the callout is completely finished, a call to
608 .Fn callout_drain
609 should be used.
610 .Sh RETURN VALUES
611 The
612 .Fn timeout
613 function returns a
614 .Ft struct callout_handle
615 that can be passed to
616 .Fn untimeout .
617 The
618 .Fn callout_stop
619 and
620 .Fn callout_drain
621 functions return non-zero if the callout was still pending when it was
622 called or zero otherwise.
623 .Sh HISTORY
624 The current timeout and untimeout routines are based on the work of
625 .An Adam M. Costello
626 and
627 .An George Varghese ,
628 published in a technical report entitled
629 .%T "Redesigning the BSD Callout and Timer Facilities"
630 and modified slightly for inclusion in
631 .Fx
632 by
633 .An Justin T. Gibbs .
634 The original work on the data structures used in this implementation
635 was published by
636 .An G. Varghese
637 and
638 .An A. Lauck
639 in the paper
640 .%T "Hashed and Hierarchical Timing Wheels: Data Structures for the Efficient Implementation of a Timer Facility"
641 in the
642 .%B "Proceedings of the 11th ACM Annual Symposium on Operating Systems Principles" .
643 The current implementation replaces the long standing
644 .Bx
645 linked list
646 callout mechanism which offered O(n) insertion and removal running time
647 but did not generate or require handles for untimeout operations.