]> CyberLeo.Net >> Repos - FreeBSD/stable/10.git/blob - share/man/man9/timeout.9
Merge r270251 from head:
[FreeBSD/stable/10.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 .El
376 .Pp
377 The functions
378 .Fn callout_reset_curcpu
379 and
380 .Fn callout_schedule_curcpu
381 are wrappers for
382 .Fn callout_reset_on
383 and
384 .Fn callout_schedule_on
385 using the current CPU as the target CPU.
386 .Pp
387 The macros
388 .Fn callout_pending ,
389 .Fn callout_active
390 and
391 .Fn callout_deactivate
392 provide access to the current state of the callout.
393 Careful use of these macros can avoid many of the race conditions
394 that are inherent in asynchronous timer facilities; see
395 .Sx "Avoiding Race Conditions"
396 below for further details.
397 The
398 .Fn callout_pending
399 macro checks whether a callout is
400 .Em pending ;
401 a callout is considered
402 .Em pending
403 when a timeout has been set but the time has not yet arrived.
404 Note that once the timeout time arrives and the callout subsystem
405 starts to process this callout,
406 .Fn callout_pending
407 will return
408 .Dv FALSE
409 even though the callout function may not have finished (or even begun)
410 executing.
411 The
412 .Fn callout_active
413 macro checks whether a callout is marked as
414 .Em active ,
415 and the
416 .Fn callout_deactivate
417 macro clears the callout's
418 .Em active
419 flag.
420 The callout subsystem marks a callout as
421 .Em active
422 when a timeout is set and it clears the
423 .Em active
424 flag in
425 .Fn callout_stop
426 and
427 .Fn callout_drain ,
428 but it
429 .Em does not
430 clear it when a callout expires normally via the execution of the
431 callout function.
432 .Ss "Avoiding Race Conditions"
433 The callout subsystem invokes callout functions from its own timer
434 context.
435 Without some kind of synchronization it is possible that a callout
436 function will be invoked concurrently with an attempt to stop or reset
437 the callout by another thread.
438 In particular, since callout functions typically acquire a mutex as
439 their first action, the callout function may have already been invoked,
440 but be blocked waiting for that mutex at the time that another thread
441 tries to reset or stop the callout.
442 .Pp
443 The callout subsystem provides a number of mechanisms to address these
444 synchronization concerns:
445 .Bl -enum -offset indent
446 .It
447 If the callout has an associated mutex that was specified using the
448 .Fn callout_init_mtx
449 function (or implicitly specified as the
450 .Va Giant
451 mutex using
452 .Fn callout_init
453 with
454 .Fa mpsafe
455 set to
456 .Dv FALSE ) ,
457 then this mutex is used to avoid the race conditions.
458 The associated mutex must be acquired by the caller before calling
459 .Fn callout_stop
460 or
461 .Fn callout_reset
462 and it is guaranteed that the callout will be correctly stopped
463 or reset as expected.
464 Note that it is still necessary to use
465 .Fn callout_drain
466 before destroying the callout or its associated mutex.
467 .It
468 The return value from
469 .Fn callout_stop
470 and
471 .Fn callout_reset
472 indicates whether or not the callout was removed.
473 If it is known that the callout was set and the callout function has
474 not yet executed, then a return value of
475 .Dv FALSE
476 indicates that the callout function is about to be called.
477 For example:
478 .Bd -literal -offset indent
479 if (sc->sc_flags & SCFLG_CALLOUT_RUNNING) {
480         if (callout_stop(&sc->sc_callout)) {
481                 sc->sc_flags &= ~SCFLG_CALLOUT_RUNNING;
482                 /* successfully stopped */
483         } else {
484                 /*
485                  * callout has expired and callout
486                  * function is about to be executed
487                  */
488         }
489 }
490 .Ed
491 .It
492 The
493 .Fn callout_pending ,
494 .Fn callout_active
495 and
496 .Fn callout_deactivate
497 macros can be used together to work around the race conditions.
498 When a callout's timeout is set, the callout subsystem marks the
499 callout as both
500 .Em active
501 and
502 .Em pending .
503 When the timeout time arrives, the callout subsystem begins processing
504 the callout by first clearing the
505 .Em pending
506 flag.
507 It then invokes the callout function without changing the
508 .Em active
509 flag, and does not clear the
510 .Em active
511 flag even after the callout function returns.
512 The mechanism described here requires the callout function itself to
513 clear the
514 .Em active
515 flag using the
516 .Fn callout_deactivate
517 macro.
518 The
519 .Fn callout_stop
520 and
521 .Fn callout_drain
522 functions always clear both the
523 .Em active
524 and
525 .Em pending
526 flags before returning.
527 .Pp
528 The callout function should first check the
529 .Em pending
530 flag and return without action if
531 .Fn callout_pending
532 returns
533 .Dv TRUE .
534 This indicates that the callout was rescheduled using
535 .Fn callout_reset
536 just before the callout function was invoked.
537 If
538 .Fn callout_active
539 returns
540 .Dv FALSE
541 then the callout function should also return without action.
542 This indicates that the callout has been stopped.
543 Finally, the callout function should call
544 .Fn callout_deactivate
545 to clear the
546 .Em active
547 flag.
548 For example:
549 .Bd -literal -offset indent
550 mtx_lock(&sc->sc_mtx);
551 if (callout_pending(&sc->sc_callout)) {
552         /* callout was reset */
553         mtx_unlock(&sc->sc_mtx);
554         return;
555 }
556 if (!callout_active(&sc->sc_callout)) {
557         /* callout was stopped */
558         mtx_unlock(&sc->sc_mtx);
559         return;
560 }
561 callout_deactivate(&sc->sc_callout);
562 /* rest of callout function */
563 .Ed
564 .Pp
565 Together with appropriate synchronization, such as the mutex used above,
566 this approach permits the
567 .Fn callout_stop
568 and
569 .Fn callout_reset
570 functions to be used at any time without races.
571 For example:
572 .Bd -literal -offset indent
573 mtx_lock(&sc->sc_mtx);
574 callout_stop(&sc->sc_callout);
575 /* The callout is effectively stopped now. */
576 .Ed
577 .Pp
578 If the callout is still pending then these functions operate normally,
579 but if processing of the callout has already begun then the tests in
580 the callout function cause it to return without further action.
581 Synchronization between the callout function and other code ensures that
582 stopping or resetting the callout will never be attempted while the
583 callout function is past the
584 .Fn callout_deactivate
585 call.
586 .Pp
587 The above technique additionally ensures that the
588 .Em active
589 flag always reflects whether the callout is effectively enabled or
590 disabled.
591 If
592 .Fn callout_active
593 returns false, then the callout is effectively disabled, since even if
594 the callout subsystem is actually just about to invoke the callout
595 function, the callout function will return without action.
596 .El
597 .Pp
598 There is one final race condition that must be considered when a
599 callout is being stopped for the last time.
600 In this case it may not be safe to let the callout function itself
601 detect that the callout was stopped, since it may need to access
602 data objects that have already been destroyed or recycled.
603 To ensure that the callout is completely finished, a call to
604 .Fn callout_drain
605 should be used.
606 .Sh RETURN VALUES
607 The
608 .Fn timeout
609 function returns a
610 .Ft struct callout_handle
611 that can be passed to
612 .Fn untimeout .
613 The
614 .Fn callout_stop
615 and
616 .Fn callout_drain
617 functions return non-zero if the callout was still pending when it was
618 called or zero otherwise.
619 .Sh HISTORY
620 The current timeout and untimeout routines are based on the work of
621 .An Adam M. Costello
622 and
623 .An George Varghese ,
624 published in a technical report entitled
625 .%T "Redesigning the BSD Callout and Timer Facilities"
626 and modified slightly for inclusion in
627 .Fx
628 by
629 .An Justin T. Gibbs .
630 The original work on the data structures used in this implementation
631 was published by
632 .An G. Varghese
633 and
634 .An A. Lauck
635 in the paper
636 .%T "Hashed and Hierarchical Timing Wheels: Data Structures for the Efficient Implementation of a Timer Facility"
637 in the
638 .%B "Proceedings of the 11th ACM Annual Symposium on Operating Systems Principles" .
639 The current implementation replaces the long standing
640 .Bx
641 linked list
642 callout mechanism which offered O(n) insertion and removal running time
643 but did not generate or require handles for untimeout operations.