1.\" $NetBSD: callout.9,v 1.25 2009/08/03 23:29:19 rmind Exp $ 2.\" 3.\" Copyright (c) 2000, 2003, 2009 The NetBSD Foundation, Inc. 4.\" All rights reserved. 5.\" 6.\" This code is derived from software contributed to The NetBSD Foundation 7.\" by Jason R. Thorpe. 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 FOUNDATION OR CONTRIBUTORS 22.\" BE 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.Dd August 3, 2009 31.Dt CALLOUT 9 32.Os 33.Sh NAME 34.Nm callout_init , 35.Nm callout_destroy , 36.Nm callout_halt , 37.Nm callout_reset , 38.Nm callout_schedule , 39.Nm callout_setfunc , 40.Nm callout_stop , 41.Nm callout_pending , 42.Nm callout_expired , 43.Nm callout_invoking , 44.Nm callout_ack 45.Nd execute a function after a specified length of time 46.Sh SYNOPSIS 47.In sys/callout.h 48.Ft void 49.Fn "callout_init" "callout_t *c" "u_int flags" 50.Ft void 51.Fn "callout_destroy" "callout_t *c" 52.Ft void 53.Fn "callout_reset" "callout_t *c" "int ticks" \ 54 "void (*func)(void *)" "void *arg" 55.Ft void 56.Fn "callout_schedule" "callout_t *c" "int ticks" 57.Ft void 58.Fn "callout_setfunc" "callout_t *c" "void (*func)(void *)" "void *arg" 59.Ft bool 60.Fn "callout_stop" "callout_t *c" 61.Ft bool 62.Fn "callout_halt" "callout_t *c" "kmutex_t *interlock" 63.Ft bool 64.Fn "callout_pending" "callout_t *c" 65.Ft bool 66.Fn "callout_expired" "callout_t *c" 67.Ft bool 68.Fn "callout_active" "callout_t *c" 69.Ft bool 70.Fn "callout_invoking" "callout_t *c" 71.Ft bool 72.Fn "callout_ack" "callout_t *c" 73.Sh DESCRIPTION 74The 75.Nm callout 76facility provides a mechanism to execute a function at a given time. 77The timer is based on the hardclock timer which ticks 78.Dv hz 79times per second. 80The function is called at softclock interrupt level. 81.Pp 82Clients of the 83.Nm callout 84facility are responsible for providing pre-allocated 85callout structures, or 86.Dq handles . 87The 88.Nm callout 89facility replaces the historic 90.Ux 91functions 92.Fn timeout 93and 94.Fn untimeout . 95.Sh FUNCTIONS 96The 97.Fn callout_init 98function initializes the callout handle 99.Fa c 100for use. 101No operations can be performed on the callout before it is initialized. 102If the 103.Fa flags 104argument is 105.Dv CALLOUT_MPSAFE , 106the handler will be called without getting the global kernel lock. 107In this case it should only use functions that are multiprocessor 108safe. 109.Pp 110.Fn callout_destroy 111destroys the callout, preventing further use. 112It is provided as a diagnostic facility intended to catch bugs. 113To ensure future compatibility, 114.Fn callout_destroy 115should always be called when the callout is no longer required (for instance, 116when a device is being detached). 117.Pp 118The 119.Fn callout_reset 120function resets and starts the timer associated with the callout handle 121.Fa c . 122When the timer expires after 123.Fa ticks Ns No /hz 124seconds, the function specified by 125.Fa func 126will be called with the argument 127.Fa arg . 128If the timer associated with the callout handle is already running, 129the callout will simply be rescheduled to execute at the newly specified 130time. 131Once the timer is started, the callout handle is marked as 132.Em PENDING . 133Once the timer expires, 134the handle is marked as 135.Em EXPIRED 136and 137.Em INVOKING , 138and the 139.Em PENDING 140status is cleared. 141.Pp 142The 143.Fn callout_setfunc 144function sets the function and argument of the callout handle 145.Fa c 146to 147.Fa func 148and 149.Fa arg 150respectively. 151The callout handle must already be initialized. 152If a callout will always be used with the same function and argument, 153then 154.Fn callout_setfunc 155used in conjunction with 156.Fn callout_schedule 157is slightly more efficient than using 158.Fn callout_reset . 159.Pp 160The 161.Fn callout_stop 162function requests that the timer associated with the callout handle 163.Fa c 164be stopped. 165The 166.Em PENDING 167and 168.Em EXPIRED 169status for the callout handle is cleared. 170It is safe to call 171.Fn callout_stop 172on a callout handle that is not pending, so long as it is initialized. 173.Fn callout_stop 174will return a non-zero value if the callout was 175.Em EXPIRED . 176Note that 177.Fn callout_stop 178can return while the callout is running on a different CPU or at a 179different interrupt priority level on the current CPU. 180It can only be said to prevent the callout from firing in the future, 181unless explicitly re-scheduled. 182To stop a callout and wait for completion, use 183.Fn callout_halt . 184.Pp 185.Fn callout_halt 186acts much like 187.Fn callout_stop , 188but waits for the callout to complete if it is currently in-flight. 189.Fn callout_halt 190may not be called from a hard interrupt handler as it will sleep if the 191callout is currently executing. 192If the callout can take locks (such as mutexes or RW locks), the caller of 193.Fn callout_halt 194must not hold any of those locks, otherwise the two could deadlock. 195To facilitate this, 196.Fn callout_halt 197can optionally release a single mutex specified by the 198.Fa interlock 199parameter. 200If 201.Fa interlock 202is not 203.Dv NULL 204and the calling thread must wait for the callout to complete, 205.Fa interlock 206will be released before waiting and re-acquired before returning. 207If no wait is required, 208.Fa interlock 209will not be released. 210However, to avoid race conditions the caller should always assume that 211.Fa interlock 212has been released and reacquired, and act accordingly. 213.Pp 214The 215.Fn callout_pending 216function tests the 217.Em PENDING 218status of the callout handle 219.Fa c . 220A 221.Em PENDING 222callout is one that has been started and whose function has not yet 223been called. 224Note that it is possible for a callout's timer to have expired without 225its function being called if interrupt level has not dropped low enough 226to let softclock interrupts through. 227Note that it is only safe to test 228.Em PENDING 229status when at softclock interrupt level or higher. 230.Pp 231The 232.Fn callout_expired 233function tests to see if the callout's timer has expired and its 234function called. 235.Pp 236The 237.Fn callout_active 238function returns true if a timer has been started but not explicitly stopped, 239even if it has already fired. 240.Fn callout_active foo 241is logically the same as 242.Fn callout_pending foo 243|| 244.Fn callout_expired foo ; 245it is implemented as a separate function for compatibility with 246.Fx 247and for the special case of 248.Fn TCP_TIMER_ISARMED . 249Its use is not recommended. 250.Pp 251The 252.Fn callout_invoking 253function tests the 254.Em INVOKING 255status of the callout handle 256.Fa c . 257This flag is set just before a callout's function is being called. 258Since the priority level is lowered prior to invocation of the 259callout function, other pending higher-priority code may run before 260the callout function is allowed to run. 261This may create a race condition if this higher-priority code 262deallocates storage containing one or more callout structures whose 263callout functions are about to be run. 264In such cases, one technique to prevent references to deallocated 265storage would be to test whether any callout functions are in the 266.Em INVOKING 267state using 268.Fn callout_invoking , 269and if so, to mark the data structure and defer storage 270deallocation until the callout function is allowed to run. 271For this handshake protocol to work, the callout function will 272have to use the 273.Fn callout_ack 274function to clear this flag. 275.Pp 276The 277.Fn callout_ack 278function clears the 279.Em INVOKING 280state in the callout handle 281.Fa c . 282This is used in situations where it is necessary to protect against 283the race condition described under 284.Fn callout_invoking . 285.Sh CONCURRENCY 286The callout facility performs locking internally in order to guarantee the 287atomicity of individual operations performed on callouts. 288It does not provide life cycle management of user-provided callout data 289structures, nor does it ensure that groups of operations (multiple function 290calls) are performed atomically. 291These aspects of callout management are the responsibility of the user of 292the callout facility. 293.Pp 294Scheduled callouts may be active concurrently in a context different to the 295user of the callout facility: on another CPU, or at a different interrupt 296priority level or thread on the current CPU. 297The callout facility provides only one guarantee in this regard: any given 298callout will never have multiple concurrent invocations. 299.Sh SEE ALSO 300.Xr condvar 9 , 301.Xr hz 9 , 302.Xr softint 9 , 303.Xr workqueue 9 304.Sh HISTORY 305The 306.Nm callout 307facility was implemented by Artur Grabowski and Thomas Nordin, based 308on the work of G. Varghese and A. Lauck, described in the paper 309Hashed and Hierarchical Timing Wheels: Data Structures for the 310Efficient Implementation of a Timer Facility 311in the Proceedings of the 11th ACM Annual Symposium on Operating System 312Principles, Austin, Texas, November 1987. 313It was adapted to the 314.Nx 315kernel by Jason R. Thorpe. 316