1.\" $NetBSD: callout.9,v 1.29 2020/01/12 20:49:21 sevan 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 January 12, 2020 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" "void *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 void 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). 117The callout should be stopped before 118.Fn callout_destroy 119is called by calling 120.Fn callout_halt . 121Note that 122.Fn callout_stop 123shouldn't be used for this purpose. 124.Pp 125The 126.Fn callout_reset 127function resets and starts the timer associated with the callout handle 128.Fa c . 129When the timer expires after 130.Fa ticks Ns No /hz 131seconds, the function specified by 132.Fa func 133will be called with the argument 134.Fa arg . 135If the timer associated with the callout handle is already running, 136the callout will simply be rescheduled to execute at the newly specified 137time. 138Once the timer is started, the callout handle is marked as 139.Em PENDING . 140Once the timer expires, 141the handle is marked as 142.Em EXPIRED 143and 144.Em INVOKING , 145and the 146.Em PENDING 147status is cleared. 148.Pp 149The 150.Fn callout_setfunc 151function sets the function and argument of the callout handle 152.Fa c 153to 154.Fa func 155and 156.Fa arg 157respectively. 158The callout handle must already be initialized. 159If a callout will always be used with the same function and argument, 160then 161.Fn callout_setfunc 162used in conjunction with 163.Fn callout_schedule 164is slightly more efficient than using 165.Fn callout_reset . 166.Pp 167The 168.Fn callout_stop 169function requests that the timer associated with the callout handle 170.Fa c 171be stopped. 172The 173.Em PENDING 174and 175.Em EXPIRED 176status for the callout handle is cleared. 177It is safe to call 178.Fn callout_stop 179on a callout handle that is not pending, so long as it is initialized. 180.Fn callout_stop 181will return a non-zero value if the callout was 182.Em EXPIRED . 183Note that 184.Fn callout_stop 185can return while the callout is running on a different CPU or at a 186different interrupt priority level on the current CPU. 187It can only be said to prevent the callout from firing in the future, 188unless explicitly re-scheduled. 189To stop a callout and wait for completion, use 190.Fn callout_halt . 191.Pp 192.Fn callout_halt 193acts much like 194.Fn callout_stop , 195but waits for the callout to complete if it is currently in-flight. 196.Fn callout_halt 197may not be called from a hard interrupt handler as it will sleep if the 198callout is currently executing. 199If the callout can take locks (such as mutexes or RW locks), the caller of 200.Fn callout_halt 201must not hold any of those locks, otherwise the two could deadlock. 202To facilitate this, 203.Fn callout_halt 204can optionally release a single mutex specified by the 205.Fa interlock 206parameter. 207If 208.Fa interlock 209is not 210.Dv NULL 211and the calling thread must wait for the callout to complete, 212.Fa interlock 213will be released before waiting and re-acquired before returning. 214If no wait is required, 215.Fa interlock 216will not be released. 217However, to avoid race conditions the caller should always assume that 218.Fa interlock 219has been released and reacquired, and act accordingly. 220.Pp 221The 222.Fn callout_pending 223function tests the 224.Em PENDING 225status of the callout handle 226.Fa c . 227A 228.Em PENDING 229callout is one that has been started and whose function has not yet 230been called. 231Note that it is possible for a callout's timer to have expired without 232its function being called if interrupt level has not dropped low enough 233to let softclock interrupts through. 234Note that it is only safe to test 235.Em PENDING 236status when at softclock interrupt level or higher. 237.Pp 238The 239.Fn callout_expired 240function tests to see if the callout's timer has expired and its 241function called. 242.Pp 243The 244.Fn callout_active 245function returns true if a timer has been started but not explicitly stopped, 246even if it has already fired. 247.Fn callout_active foo 248is logically the same as 249.Fn callout_pending foo 250|| 251.Fn callout_expired foo ; 252it is implemented as a separate function for compatibility with 253.Fx 254and for the special case of 255.Fn TCP_TIMER_ISARMED . 256Its use is not recommended. 257.Pp 258The 259.Fn callout_invoking 260function tests the 261.Em INVOKING 262status of the callout handle 263.Fa c . 264This flag is set just before a callout's function is being called. 265Since the priority level is lowered prior to invocation of the 266callout function, other pending higher-priority code may run before 267the callout function is allowed to run. 268This may create a race condition if this higher-priority code 269deallocates storage containing one or more callout structures whose 270callout functions are about to be run. 271In such cases, one technique to prevent references to deallocated 272storage would be to test whether any callout functions are in the 273.Em INVOKING 274state using 275.Fn callout_invoking , 276and if so, to mark the data structure and defer storage 277deallocation until the callout function is allowed to run. 278For this handshake protocol to work, the callout function will 279have to use the 280.Fn callout_ack 281function to clear this flag. 282.Pp 283The 284.Fn callout_ack 285function clears the 286.Em INVOKING 287state in the callout handle 288.Fa c . 289This is used in situations where it is necessary to protect against 290the race condition described under 291.Fn callout_invoking . 292.Sh CONCURRENCY 293The callout facility performs locking internally in order to guarantee the 294atomicity of individual operations performed on callouts. 295It does not provide life cycle management of user-provided callout data 296structures, nor does it ensure that groups of operations (multiple function 297calls) are performed atomically. 298These aspects of callout management are the responsibility of the user of 299the callout facility. 300.Pp 301Scheduled callouts may be active concurrently in a context different to the 302user of the callout facility: on another CPU, or at a different interrupt 303priority level or thread on the current CPU. 304The callout facility provides only one guarantee in this regard: any given 305callout will never have multiple concurrent invocations. 306.Sh SEE ALSO 307.Xr condvar 9 , 308.Xr hz 9 , 309.Xr softint 9 , 310.Xr workqueue 9 311.Sh HISTORY 312The 313.Nm callout 314facility was implemented by Artur Grabowski and Thomas Nordin, based 315on the work of G. Varghese and A. Lauck, described in the paper 316Hashed and Hierarchical Timing Wheels: Data Structures for the 317Efficient Implementation of a Timer Facility 318in the Proceedings of the 11th ACM Annual Symposium on Operating System 319Principles, Austin, Texas, November 1987. 320It was adapted to the 321.Nx 322kernel by Jason R. Thorpe. 323