]> CyberLeo.Net >> Repos - FreeBSD/FreeBSD.git/blob - share/man/man9/timeout.9
Import tzdata 2018c
[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 July 27, 2016
33 .Dt TIMEOUT 9
34 .Os
35 .Sh NAME
36 .Nm callout_active ,
37 .Nm callout_deactivate ,
38 .Nm callout_async_drain ,
39 .Nm callout_drain ,
40 .Nm callout_handle_init ,
41 .Nm callout_init ,
42 .Nm callout_init_mtx ,
43 .Nm callout_init_rm ,
44 .Nm callout_init_rw ,
45 .Nm callout_pending ,
46 .Nm callout_reset ,
47 .Nm callout_reset_curcpu ,
48 .Nm callout_reset_on ,
49 .Nm callout_reset_sbt ,
50 .Nm callout_reset_sbt_curcpu ,
51 .Nm callout_reset_sbt_on ,
52 .Nm callout_schedule ,
53 .Nm callout_schedule_curcpu ,
54 .Nm callout_schedule_on ,
55 .Nm callout_schedule_sbt ,
56 .Nm callout_schedule_sbt_curcpu ,
57 .Nm callout_schedule_sbt_on ,
58 .Nm callout_stop ,
59 .Nm callout_when ,
60 .Nm timeout ,
61 .Nm untimeout
62 .Nd execute a function after a specified length of time
63 .Sh SYNOPSIS
64 .In sys/types.h
65 .In sys/systm.h
66 .Bd -literal
67 typedef void timeout_t (void *);
68 .Ed
69 .Ft int
70 .Fn callout_active "struct callout *c"
71 .Ft void
72 .Fn callout_deactivate "struct callout *c"
73 .Ft int
74 .Fn callout_async_drain "struct callout *c" "timeout_t *drain"
75 .Ft int
76 .Fn callout_drain "struct callout *c"
77 .Ft void
78 .Fn callout_handle_init "struct callout_handle *handle"
79 .Bd -literal
80 struct callout_handle handle = CALLOUT_HANDLE_INITIALIZER(&handle);
81 .Ed
82 .Ft void
83 .Fn callout_init "struct callout *c" "int mpsafe"
84 .Ft void
85 .Fn callout_init_mtx "struct callout *c" "struct mtx *mtx" "int flags"
86 .Ft void
87 .Fn callout_init_rm "struct callout *c" "struct rmlock *rm" "int flags"
88 .Ft void
89 .Fn callout_init_rw "struct callout *c" "struct rwlock *rw" "int flags"
90 .Ft int
91 .Fn callout_pending "struct callout *c"
92 .Ft int
93 .Fn callout_reset "struct callout *c" "int ticks" "timeout_t *func" "void *arg"
94 .Ft int
95 .Fo callout_reset_curcpu
96 .Fa "struct callout *c"
97 .Fa "int ticks"
98 .Fa "timeout_t *func"
99 .Fa "void *arg"
100 .Fc
101 .Ft int
102 .Fo callout_reset_on
103 .Fa "struct callout *c"
104 .Fa "int ticks"
105 .Fa "timeout_t *func"
106 .Fa "void *arg"
107 .Fa "int cpu"
108 .Fc
109 .Ft int
110 .Fo callout_reset_sbt
111 .Fa "struct callout *c"
112 .Fa "sbintime_t sbt"
113 .Fa "sbintime_t pr"
114 .Fa "timeout_t *func"
115 .Fa "void *arg"
116 .Fa "int flags"
117 .Fc
118 .Ft int
119 .Fo callout_reset_sbt_curcpu
120 .Fa "struct callout *c"
121 .Fa "sbintime_t sbt"
122 .Fa "sbintime_t pr"
123 .Fa "timeout_t *func"
124 .Fa "void *arg"
125 .Fa "int flags"
126 .Fc
127 .Ft int
128 .Fo callout_reset_sbt_on
129 .Fa "struct callout *c"
130 .Fa "sbintime_t sbt"
131 .Fa "sbintime_t pr"
132 .Fa "timeout_t *func"
133 .Fa "void *arg"
134 .Fa "int cpu"
135 .Fa "int flags"
136 .Fc
137 .Ft int
138 .Fn callout_schedule "struct callout *c" "int ticks"
139 .Ft int
140 .Fn callout_schedule_curcpu "struct callout *c" "int ticks"
141 .Ft int
142 .Fn callout_schedule_on "struct callout *c" "int ticks" "int cpu"
143 .Ft int
144 .Fo callout_schedule_sbt
145 .Fa "struct callout *c"
146 .Fa "sbintime_t sbt"
147 .Fa "sbintime_t pr"
148 .Fa "int flags"
149 .Fc
150 .Ft int
151 .Fo callout_schedule_sbt_curcpu
152 .Fa "struct callout *c"
153 .Fa "sbintime_t sbt"
154 .Fa "sbintime_t pr"
155 .Fa "int flags"
156 .Fc
157 .Ft int
158 .Fo callout_schedule_sbt_on
159 .Fa "struct callout *c"
160 .Fa "sbintime_t sbt"
161 .Fa "sbintime_t pr"
162 .Fa "int cpu"
163 .Fa "int flags"
164 .Fc
165 .Ft int
166 .Fn callout_stop "struct callout *c"
167 .Ft sbintime_t
168 .Fo callout_when
169 .Fa "sbintime_t sbt"
170 .Fa "sbintime_t precision"
171 .Fa "int flags"
172 .Fa "sbintime_t *sbt_res"
173 .Fa "sbintime_t *precision_res"
174 .Fc
175 .Ft struct callout_handle
176 .Fn timeout "timeout_t *func" "void *arg" "int ticks"
177 .Ft void
178 .Fn untimeout "timeout_t *func" "void *arg" "struct callout_handle handle"
179 .Sh DESCRIPTION
180 The
181 .Nm callout
182 API is used to schedule a call to an arbitrary function at a specific
183 time in the future.
184 Consumers of this API are required to allocate a callout structure
185 .Pq struct callout
186 for each pending function invocation.
187 This structure stores state about the pending function invocation including
188 the function to be called and the time at which the function should be invoked.
189 Pending function calls can be cancelled or rescheduled to a different time.
190 In addition,
191 a callout structure may be reused to schedule a new function call after a
192 scheduled call is completed.
193 .Pp
194 Callouts only provide a single-shot mode.
195 If a consumer requires a periodic timer,
196 it must explicitly reschedule each function call.
197 This is normally done by rescheduling the subsequent call within the called
198 function.
199 .Pp
200 Callout functions must not sleep.
201 They may not acquire sleepable locks,
202 wait on condition variables,
203 perform blocking allocation requests,
204 or invoke any other action that might sleep.
205 .Pp
206 Each callout structure must be initialized by
207 .Fn callout_init ,
208 .Fn callout_init_mtx ,
209 .Fn callout_init_rm ,
210 or
211 .Fn callout_init_rw
212 before it is passed to any of the other callout functions.
213 The
214 .Fn callout_init
215 function initializes a callout structure in
216 .Fa c
217 that is not associated with a specific lock.
218 If the
219 .Fa mpsafe
220 argument is zero,
221 the callout structure is not considered to be
222 .Dq multi-processor safe ;
223 and the Giant lock will be acquired before calling the callout function
224 and released when the callout function returns.
225 .Pp
226 The
227 .Fn callout_init_mtx ,
228 .Fn callout_init_rm ,
229 and
230 .Fn callout_init_rw
231 functions initialize a callout structure in
232 .Fa c
233 that is associated with a specific lock.
234 The lock is specified by the
235 .Fa mtx ,
236 .Fa rm ,
237 or
238 .Fa rw
239 parameter.
240 The associated lock must be held while stopping or rescheduling the
241 callout.
242 The callout subsystem acquires the associated lock before calling the
243 callout function and releases it after the function returns.
244 If the callout was cancelled while the callout subsystem waited for the
245 associated lock,
246 the callout function is not called,
247 and the associated lock is released.
248 This ensures that stopping or rescheduling the callout will abort any
249 previously scheduled invocation.
250 .Pp
251 Only regular mutexes may be used with
252 .Fn callout_init_mtx ;
253 spin mutexes are not supported.
254 A sleepable read-mostly lock
255 .Po
256 one initialized with the
257 .Dv RM_SLEEPABLE
258 flag
259 .Pc
260 may not be used with
261 .Fn callout_init_rm .
262 Similarly, other sleepable lock types such as
263 .Xr sx 9
264 and
265 .Xr lockmgr 9
266 cannot be used with callouts because sleeping is not permitted in
267 the callout subsystem.
268 .Pp
269 These
270 .Fa flags
271 may be specified for
272 .Fn callout_init_mtx ,
273 .Fn callout_init_rm ,
274 or
275 .Fn callout_init_rw :
276 .Bl -tag -width ".Dv CALLOUT_RETURNUNLOCKED"
277 .It Dv CALLOUT_RETURNUNLOCKED
278 The callout function will release the associated lock itself,
279 so the callout subsystem should not attempt to unlock it
280 after the callout function returns.
281 .It Dv CALLOUT_SHAREDLOCK
282 The lock is only acquired in read mode when running the callout handler.
283 This flag is ignored by
284 .Fn callout_init_mtx .
285 .El
286 .Pp
287 The function
288 .Fn callout_stop
289 cancels a callout
290 .Fa c
291 if it is currently pending.
292 If the callout is pending and successfully stopped, then
293 .Fn callout_stop
294 returns a value of one.
295 If the callout is not set, or
296 has already been serviced, then
297 negative one is returned.
298 If the callout is currently being serviced and cannot be stopped,
299 then zero will be returned.
300 If the callout is currently being serviced and cannot be stopped, and at the
301 same time a next invocation of the same callout is also scheduled, then
302 .Fn callout_stop
303 unschedules the next run and returns zero.
304 If the callout has an associated lock,
305 then that lock must be held when this function is called.
306 .Pp
307 The function
308 .Fn callout_async_drain
309 is identical to
310 .Fn callout_stop
311 with one difference.
312 When
313 .Fn callout_async_drain
314 returns zero it will arrange for the function
315 .Fa drain
316 to be called using the same argument given to the
317 .Fn callout_reset
318 function.
319 .Fn callout_async_drain
320 If the callout has an associated lock,
321 then that lock must be held when this function is called.
322 Note that when stopping multiple callouts that use the same lock it is possible
323 to get multiple return's of zero and multiple calls to the
324 .Fa drain
325 function, depending upon which CPU's the callouts are running.
326 The
327 .Fa drain
328 function itself is called from the context of the completing callout
329 i.e. softclock or hardclock, just like a callout itself.
330 p
331 .Pp
332 The function
333 .Fn callout_drain
334 is identical to
335 .Fn callout_stop
336 except that it will wait for the callout
337 .Fa c
338 to complete if it is already in progress.
339 This function MUST NOT be called while holding any
340 locks on which the callout might block, or deadlock will result.
341 Note that if the callout subsystem has already begun processing this
342 callout, then the callout function may be invoked before
343 .Fn callout_drain
344 returns.
345 However, the callout subsystem does guarantee that the callout will be
346 fully stopped before
347 .Fn callout_drain
348 returns.
349 .Pp
350 The
351 .Fn callout_reset
352 and
353 .Fn callout_schedule
354 function families schedule a future function invocation for callout
355 .Fa c .
356 If
357 .Fa c
358 already has a pending callout,
359 it is cancelled before the new invocation is scheduled.
360 These functions return a value of one if a pending callout was cancelled
361 and zero if there was no pending callout.
362 If the callout has an associated lock,
363 then that lock must be held when any of these functions are called.
364 .Pp
365 The time at which the callout function will be invoked is determined by
366 either the
367 .Fa ticks
368 argument or the
369 .Fa sbt ,
370 .Fa pr ,
371 and
372 .Fa flags
373 arguments.
374 When
375 .Fa ticks
376 is used,
377 the callout is scheduled to execute after
378 .Fa ticks Ns No /hz
379 seconds.
380 Non-positive values of
381 .Fa ticks
382 are silently converted to the value
383 .Sq 1 .
384 .Pp
385 The
386 .Fa sbt ,
387 .Fa pr ,
388 and
389 .Fa flags
390 arguments provide more control over the scheduled time including
391 support for higher resolution times,
392 specifying the precision of the scheduled time,
393 and setting an absolute deadline instead of a relative timeout.
394 The callout is scheduled to execute in a time window which begins at
395 the time specified in
396 .Fa sbt
397 and extends for the amount of time specified in
398 .Fa pr .
399 If
400 .Fa sbt
401 specifies a time in the past,
402 the window is adjusted to start at the current time.
403 A non-zero value for
404 .Fa pr
405 allows the callout subsystem to coalesce callouts scheduled close to each
406 other into fewer timer interrupts,
407 reducing processing overhead and power consumption.
408 These
409 .Fa flags
410 may be specified to adjust the interpretation of
411 .Fa sbt
412 and
413 .Fa pr :
414 .Bl -tag -width ".Dv C_DIRECT_EXEC"
415 .It Dv C_ABSOLUTE
416 Handle the
417 .Fa sbt
418 argument as an absolute time since boot.
419 By default,
420 .Fa sbt
421 is treated as a relative amount of time,
422 similar to
423 .Fa ticks .
424 .It Dv C_DIRECT_EXEC
425 Run the handler directly from hardware interrupt context instead of from the
426 softclock thread.
427 This reduces latency and overhead, but puts more constraints on the callout
428 function.
429 Callout functions run in this context may use only spin mutexes for locking
430 and should be as small as possible because they run with absolute priority.
431 .It Fn C_PREL
432 Specifies relative event time precision as binary logarithm of time interval
433 divided by acceptable time deviation: 1 -- 1/2, 2 -- 1/4, etc.
434 Note that the larger of
435 .Fa pr
436 or this value is used as the length of the time window.
437 Smaller values
438 .Pq which result in larger time intervals
439 allow the callout subsystem to aggregate more events in one timer interrupt.
440 .It Dv C_PRECALC
441 The
442 .Fa sbt
443 argument specifies the absolute time at which the callout should be run,
444 and the
445 .Fa pr
446 argument specifies the requested precision, which will not be
447 adjusted during the scheduling process.
448 The
449 .Fa sbt
450 and
451 .Fa pr
452 values should be calculated by an earlier call to
453 .Fn callout_when
454 which uses the user-supplied
455 .Fa sbt ,
456 .Fa pr ,
457 and
458 .Fa flags
459 values.
460 .It Dv C_HARDCLOCK
461 Align the timeouts to
462 .Fn hardclock
463 calls if possible.
464 .El
465 .Pp
466 The
467 .Fn callout_reset
468 functions accept a
469 .Fa func
470 argument which identifies the function to be called when the time expires.
471 It must be a pointer to a function that takes a single
472 .Fa void *
473 argument.
474 Upon invocation,
475 .Fa func
476 will receive
477 .Fa arg
478 as its only argument.
479 The
480 .Fn callout_schedule
481 functions reuse the
482 .Fa func
483 and
484 .Fa arg
485 arguments from the previous callout.
486 Note that one of the
487 .Fn callout_reset
488 functions must always be called to initialize
489 .Fa func
490 and
491 .Fa arg
492 before one of the
493 .Fn callout_schedule
494 functions can be used.
495 .Pp
496 The callout subsystem provides a softclock thread for each CPU in the system.
497 Callouts are assigned to a single CPU and are executed by the softclock thread
498 for that CPU.
499 Initially,
500 callouts are assigned to CPU 0.
501 The
502 .Fn callout_reset_on ,
503 .Fn callout_reset_sbt_on ,
504 .Fn callout_schedule_on
505 and
506 .Fn callout_schedule_sbt_on
507 functions assign the callout to CPU
508 .Fa cpu .
509 The
510 .Fn callout_reset_curcpu ,
511 .Fn callout_reset_sbt_curpu ,
512 .Fn callout_schedule_curcpu
513 and
514 .Fn callout_schedule_sbt_curcpu
515 functions assign the callout to the current CPU.
516 The
517 .Fn callout_reset ,
518 .Fn callout_reset_sbt ,
519 .Fn callout_schedule
520 and
521 .Fn callout_schedule_sbt
522 functions schedule the callout to execute in the softclock thread of the CPU
523 to which it is currently assigned.
524 .Pp
525 Softclock threads are not pinned to their respective CPUs by default.
526 The softclock thread for CPU 0 can be pinned to CPU 0 by setting the
527 .Va kern.pin_default_swi
528 loader tunable to a non-zero value.
529 Softclock threads for CPUs other than zero can be pinned to their
530 respective CPUs by setting the
531 .Va kern.pin_pcpu_swi
532 loader tunable to a non-zero value.
533 .Pp
534 The macros
535 .Fn callout_pending ,
536 .Fn callout_active
537 and
538 .Fn callout_deactivate
539 provide access to the current state of the callout.
540 The
541 .Fn callout_pending
542 macro checks whether a callout is
543 .Em pending ;
544 a callout is considered
545 .Em pending
546 when a timeout has been set but the time has not yet arrived.
547 Note that once the timeout time arrives and the callout subsystem
548 starts to process this callout,
549 .Fn callout_pending
550 will return
551 .Dv FALSE
552 even though the callout function may not have finished
553 .Pq or even begun
554 executing.
555 The
556 .Fn callout_active
557 macro checks whether a callout is marked as
558 .Em active ,
559 and the
560 .Fn callout_deactivate
561 macro clears the callout's
562 .Em active
563 flag.
564 The callout subsystem marks a callout as
565 .Em active
566 when a timeout is set and it clears the
567 .Em active
568 flag in
569 .Fn callout_stop
570 and
571 .Fn callout_drain ,
572 but it
573 .Em does not
574 clear it when a callout expires normally via the execution of the
575 callout function.
576 .Pp
577 The
578 .Fn callout_when
579 function may be used to pre-calculate the absolute time at which the
580 timeout should be run and the precision of the scheduled run time
581 according to the required time
582 .Fa sbt ,
583 precision
584 .Fa precision ,
585 and additional adjustments requested by the
586 .Fa flags
587 argument.
588 Flags accepted by the
589 .Fn callout_when
590 function are the same as flags for the
591 .Fn callout_reset
592 function.
593 The resulting time is assigned to the variable pointed to by the
594 .Fa sbt_res
595 argument, and the resulting precision is assigned to
596 .Fa *precision_res .
597 When passing the results to
598 .Fa callout_reset ,
599 add the
600 .Va C_PRECALC
601 flag to
602 .Fa flags ,
603 to avoid incorrect re-adjustment.
604 The function is intended for situations where precise time of the callout
605 run should be known in advance, since
606 trying to read this time from the callout structure itself after a
607 .Fn callout_reset
608 call is racy.
609 .Ss "Avoiding Race Conditions"
610 The callout subsystem invokes callout functions from its own thread
611 context.
612 Without some kind of synchronization,
613 it is possible that a callout
614 function will be invoked concurrently with an attempt to stop or reset
615 the callout by another thread.
616 In particular, since callout functions typically acquire a lock as
617 their first action, the callout function may have already been invoked,
618 but is blocked waiting for that lock at the time that another thread
619 tries to reset or stop the callout.
620 .Pp
621 There are three main techniques for addressing these
622 synchronization concerns.
623 The first approach is preferred as it is the simplest:
624 .Bl -enum -offset indent
625 .It
626 Callouts can be associated with a specific lock when they are initialized
627 by
628 .Fn callout_init_mtx ,
629 .Fn callout_init_rm ,
630 or
631 .Fn callout_init_rw .
632 When a callout is associated with a lock,
633 the callout subsystem acquires the lock before the callout function is
634 invoked.
635 This allows the callout subsystem to transparently handle races between
636 callout cancellation,
637 scheduling,
638 and execution.
639 Note that the associated lock must be acquired before calling
640 .Fn callout_stop
641 or one of the
642 .Fn callout_reset
643 or
644 .Fn callout_schedule
645 functions to provide this safety.
646 .Pp
647 A callout initialized via
648 .Fn callout_init
649 with
650 .Fa mpsafe
651 set to zero is implicitly associated with the
652 .Va Giant
653 mutex.
654 If
655 .Va Giant
656 is held when cancelling or rescheduling the callout,
657 then its use will prevent races with the callout function.
658 .It
659 The return value from
660 .Fn callout_stop
661 .Po
662 or the
663 .Fn callout_reset
664 and
665 .Fn callout_schedule
666 function families
667 .Pc
668 indicates whether or not the callout was removed.
669 If it is known that the callout was set and the callout function has
670 not yet executed, then a return value of
671 .Dv FALSE
672 indicates that the callout function is about to be called.
673 For example:
674 .Bd -literal -offset indent
675 if (sc->sc_flags & SCFLG_CALLOUT_RUNNING) {
676         if (callout_stop(&sc->sc_callout)) {
677                 sc->sc_flags &= ~SCFLG_CALLOUT_RUNNING;
678                 /* successfully stopped */
679         } else {
680                 /*
681                  * callout has expired and callout
682                  * function is about to be executed
683                  */
684         }
685 }
686 .Ed
687 .It
688 The
689 .Fn callout_pending ,
690 .Fn callout_active
691 and
692 .Fn callout_deactivate
693 macros can be used together to work around the race conditions.
694 When a callout's timeout is set, the callout subsystem marks the
695 callout as both
696 .Em active
697 and
698 .Em pending .
699 When the timeout time arrives, the callout subsystem begins processing
700 the callout by first clearing the
701 .Em pending
702 flag.
703 It then invokes the callout function without changing the
704 .Em active
705 flag, and does not clear the
706 .Em active
707 flag even after the callout function returns.
708 The mechanism described here requires the callout function itself to
709 clear the
710 .Em active
711 flag using the
712 .Fn callout_deactivate
713 macro.
714 The
715 .Fn callout_stop
716 and
717 .Fn callout_drain
718 functions always clear both the
719 .Em active
720 and
721 .Em pending
722 flags before returning.
723 .Pp
724 The callout function should first check the
725 .Em pending
726 flag and return without action if
727 .Fn callout_pending
728 returns
729 .Dv TRUE .
730 This indicates that the callout was rescheduled using
731 .Fn callout_reset
732 just before the callout function was invoked.
733 If
734 .Fn callout_active
735 returns
736 .Dv FALSE
737 then the callout function should also return without action.
738 This indicates that the callout has been stopped.
739 Finally, the callout function should call
740 .Fn callout_deactivate
741 to clear the
742 .Em active
743 flag.
744 For example:
745 .Bd -literal -offset indent
746 mtx_lock(&sc->sc_mtx);
747 if (callout_pending(&sc->sc_callout)) {
748         /* callout was reset */
749         mtx_unlock(&sc->sc_mtx);
750         return;
751 }
752 if (!callout_active(&sc->sc_callout)) {
753         /* callout was stopped */
754         mtx_unlock(&sc->sc_mtx);
755         return;
756 }
757 callout_deactivate(&sc->sc_callout);
758 /* rest of callout function */
759 .Ed
760 .Pp
761 Together with appropriate synchronization, such as the mutex used above,
762 this approach permits the
763 .Fn callout_stop
764 and
765 .Fn callout_reset
766 functions to be used at any time without races.
767 For example:
768 .Bd -literal -offset indent
769 mtx_lock(&sc->sc_mtx);
770 callout_stop(&sc->sc_callout);
771 /* The callout is effectively stopped now. */
772 .Ed
773 .Pp
774 If the callout is still pending then these functions operate normally,
775 but if processing of the callout has already begun then the tests in
776 the callout function cause it to return without further action.
777 Synchronization between the callout function and other code ensures that
778 stopping or resetting the callout will never be attempted while the
779 callout function is past the
780 .Fn callout_deactivate
781 call.
782 .Pp
783 The above technique additionally ensures that the
784 .Em active
785 flag always reflects whether the callout is effectively enabled or
786 disabled.
787 If
788 .Fn callout_active
789 returns false, then the callout is effectively disabled, since even if
790 the callout subsystem is actually just about to invoke the callout
791 function, the callout function will return without action.
792 .El
793 .Pp
794 There is one final race condition that must be considered when a
795 callout is being stopped for the last time.
796 In this case it may not be safe to let the callout function itself
797 detect that the callout was stopped, since it may need to access
798 data objects that have already been destroyed or recycled.
799 To ensure that the callout is completely finished, a call to
800 .Fn callout_drain
801 should be used.
802 In particular,
803 a callout should always be drained prior to destroying its associated lock
804 or releasing the storage for the callout structure.
805 .Sh LEGACY API
806 .Bf Sy
807 The functions below are a legacy API that will be removed in a future release.
808 New code should not use these routines.
809 .Ef
810 .Pp
811 The function
812 .Fn timeout
813 schedules a call to the function given by the argument
814 .Fa func
815 to take place after
816 .Fa ticks Ns No /hz
817 seconds.
818 Non-positive values of
819 .Fa ticks
820 are silently converted to the value
821 .Sq 1 .
822 .Fa func
823 should be a pointer to a function that takes a
824 .Fa void *
825 argument.
826 Upon invocation,
827 .Fa func
828 will receive
829 .Fa arg
830 as its only argument.
831 The return value from
832 .Fn timeout
833 is a
834 .Ft struct callout_handle
835 which can be used in conjunction with the
836 .Fn untimeout
837 function to request that a scheduled timeout be canceled.
838 .Pp
839 The function
840 .Fn callout_handle_init
841 can be used to initialize a handle to a state which will cause
842 any calls to
843 .Fn untimeout
844 with that handle to return with no side
845 effects.
846 .Pp
847 Assigning a callout handle the value of
848 .Fn CALLOUT_HANDLE_INITIALIZER
849 performs the same function as
850 .Fn callout_handle_init
851 and is provided for use on statically declared or global callout handles.
852 .Pp
853 The function
854 .Fn untimeout
855 cancels the timeout associated with
856 .Fa handle
857 using the
858 .Fa func
859 and
860 .Fa arg
861 arguments to validate the handle.
862 If the handle does not correspond to a timeout with
863 the function
864 .Fa func
865 taking the argument
866 .Fa arg
867 no action is taken.
868 .Fa handle
869 must be initialized by a previous call to
870 .Fn timeout ,
871 .Fn callout_handle_init ,
872 or assigned the value of
873 .Fn CALLOUT_HANDLE_INITIALIZER "&handle"
874 before being passed to
875 .Fn untimeout .
876 The behavior of calling
877 .Fn untimeout
878 with an uninitialized handle
879 is undefined.
880 .Pp
881 As handles are recycled by the system, it is possible (although unlikely)
882 that a handle from one invocation of
883 .Fn timeout
884 may match the handle of another invocation of
885 .Fn timeout
886 if both calls used the same function pointer and argument, and the first
887 timeout is expired or canceled before the second call.
888 The timeout facility offers O(1) running time for
889 .Fn timeout
890 and
891 .Fn untimeout .
892 Timeouts are executed from
893 .Fn softclock
894 with the
895 .Va Giant
896 lock held.
897 Thus they are protected from re-entrancy.
898 .Sh RETURN VALUES
899 The
900 .Fn callout_active
901 macro returns the state of a callout's
902 .Em active
903 flag.
904 .Pp
905 The
906 .Fn callout_pending
907 macro returns the state of a callout's
908 .Em pending
909 flag.
910 .Pp
911 The
912 .Fn callout_reset
913 and
914 .Fn callout_schedule
915 function families return a value of one if the callout was pending before the new
916 function invocation was scheduled.
917 .Pp
918 The
919 .Fn callout_stop
920 and
921 .Fn callout_drain
922 functions return a value of one if the callout was still pending when it was
923 called, a zero if the callout could not be stopped and a negative one is it
924 was either not running or has already completed.
925 The
926 .Fn timeout
927 function returns a
928 .Ft struct callout_handle
929 that can be passed to
930 .Fn untimeout .
931 .Sh HISTORY
932 The current timeout and untimeout routines are based on the work of
933 .An Adam M. Costello
934 and
935 .An George Varghese ,
936 published in a technical report entitled
937 .%T "Redesigning the BSD Callout and Timer Facilities"
938 and modified slightly for inclusion in
939 .Fx
940 by
941 .An Justin T. Gibbs .
942 The original work on the data structures used in this implementation
943 was published by
944 .An G. Varghese
945 and
946 .An A. Lauck
947 in the paper
948 .%T "Hashed and Hierarchical Timing Wheels: Data Structures for the Efficient Implementation of a Timer Facility"
949 in the
950 .%B "Proceedings of the 11th ACM Annual Symposium on Operating Systems Principles" .
951 The current implementation replaces the long standing
952 .Bx
953 linked list
954 callout mechanism which offered O(n) insertion and removal running time
955 but did not generate or require handles for untimeout operations.