CALLOUT(9) NetBSD Kernel Developer's Manual CALLOUT(9)
NAME
callout_init, callout_destroy, callout_halt, callout_setfunc, callout_schedule, callout_reset, callout_stop, callout_pending, callout_expired, callout_invoking, callout_ack -- execute a function after a specified length of time
SYNOPSIS
#include <sys/callout.h> void callout_init(callout_t *c, u_int flags); void callout_destroy(callout_t *c); void callout_setfunc(callout_t *c, void (*func)(void *), void *arg); void callout_schedule(callout_t *c, int ticks); void callout_reset(callout_t *c, int ticks, void (*func)(void *), void *arg); bool callout_stop(callout_t *c); bool callout_halt(callout_t *c, void *interlock); bool callout_pending(callout_t *c); bool callout_expired(callout_t *c); bool callout_active(callout_t *c); bool callout_invoking(callout_t *c); void callout_ack(callout_t *c);
DESCRIPTION
The callout facility provides a mechanism to execute a function at a given time. The timer is based on the hardclock(8) timer which ticks hz times per second. The function is called at IPL_SOFTCLOCK interrupt level. Clients of the callout facility are responsible for providing pre-allo- cated callout structures, or ``handles''. The callout facility replaces the historic UNIX functions timeout() and untimeout().
FUNCTIONS
callout_init(c, flags) Initializes the callout handle c for use. No opera- tions can be performed on the callout before it is ini- tialized. If the flags argument is CALLOUT_MPSAFE, the handler will be called without getting the global ker- nel lock. In this case it should only use functions that are multiprocessor safe. callout_destroy(c) Destroys the callout, preventing further use. It is provided as a diagnostic facility intended to catch bugs. To ensure future compatibility, callout_destroy() should always be called when the callout is no longer required (for instance, when a device is being detached). The callout should be stopped before callout_destroy() is called by calling callout_halt(). Note that callout_stop() shouldn't be used for this purpose. callout_setfunc(c, func, arg) Sets the function and argument of the callout handle c to func and arg respectively, so that when the timer expires, it will call (*func)(arg). The callout handle must already be initialized. callout_schedule(c, ticks) Starts the timer associated with the callout handle c. When the timer expires after ticks/hz seconds, the function previously specified by callout_setfunc() will be called. If the timer associated with the callout handle is already running, the callout will simply be rescheduled to execute at the newly specified time. Once the timer is started, the callout handle is marked as PENDING. Once the timer expires, the handle is marked as EXPIRED and INVOKING, and the PENDING status is cleared. callout_reset(ch, ticks, func, arg) Atomically does callout_setfunc(ch, func, arg) and callout_schedule(ch, ticks) together. The callout han- dle must already be initialized. If a callout will always be used with the same function and argument, you should use callout_setfunc() in con- junction with callout_schedule(); it is clearer, and slightly more efficient, than using callout_reset(). callout_stop(c) Requests that the timer associated with the callout handle c be stopped. The PENDING and EXPIRED status for the callout handle is cleared. It is safe to call callout_stop() on a callout handle that is not pending, so long as it is initialized. callout_stop() will return a non-zero value if the callout was EXPIRED. WARNING: callout_stop() can return while the callout is running on a different CPU or at a different interrupt priority level on the current CPU. It can only be said to prevent the callout from firing in the future, unless explicitly re-scheduled. To stop a callout and wait for completion, use callout_halt(). callout_halt(c, interlock) Acts much like callout_stop(), but waits for the call- out to complete if it is currently in-flight. callout_halt() may not be called from a hard interrupt handler as it will sleep if the callout is currently executing. If the callout can take locks (such as mutex(9) or rwlock(9)), the caller of callout_halt() must not hold any of those locks; otherwise, the two could deadlock. To facilitate this, callout_halt() can optionally release a single mutex(9) specified by the interlock parameter. If interlock is not NULL and the calling thread must wait for the callout to complete, interlock will be released before waiting and re-acquired before returning. If no wait is required, interlock will not be released. However, to avoid race conditions the caller should always assume that interlock has been released and reacquired, and act accordingly. callout_pending(c) Tests the PENDING status of the callout handle c. A PENDING callout is one that has been started and whose function has not yet been called. Note that it is pos- sible for a callout's timer to have expired without its function being called if interrupt level has not dropped low enough to let softclock interrupts through. Note that it is only safe to test PENDING status when at softclock interrupt level or higher. callout_expired(c) Tests to see if the callout's timer has expired. If this returns true, then either the callout's function has already been called or is guaranteed to be called, even if callout_stop() or callout_halt() are later used. callout_active(c) Returns true if a timer has been started but not explicitly stopped, even if it has already fired. callout_active(c) is logically the same as callout_pending(c) || callout_expired(c) it is implemented as a separate function for compati- bility with FreeBSD and for the special case of TCP_TIMER_ISARMED(). Its use is not recommended. callout_invoking(c) Tests the INVOKING status of the callout handle c. This flag is set just before a callout's function is being called. This is useful in scenarios when concurrent or higher- priority code which can't sleep stops a callout with callout_stop() potentially just before it has expired, and seeks to deallocate storage which the callout might use. Since the code can't sleep, it can't use callout_halt() to wait for the callout to finish. Instead, it needs to distinguish three cases: 1. the callout has not yet expired, 2. the callout has expired but has not yet begun to use the storage, 3. the callout has expired and is already using the storage. In such scenarios, one technique to prevent references to deallocated storage would be to test whether any callout functions are in the INVOKING state using callout_invoking(), and if so, to mark the data struc- ture and defer storage deallocation until the callout function is allowed to run. For this handshake proto- col to work, the callout function will have to use the callout_ack() function to clear this flag, typically after taking a lock: mutex_enter(&sc->sc_lock); if (!callout_stop(ch)) { /* 1. callout has not yet expired */ } else if (callout_invoking(ch)) { /* 2. callout has expired but not acked */ } else { /* 3. callout expired and acked */ } mutex_exit(&sc->sc_lock); /* callout function */ static void driver_intr(void *arg) { struct driver_softc *sc = arg; /* 2. callout has expired but not acked */ mutex_enter(&sc->sc_lock); callout_ack(&sc->sc_timeout); /* 3. callout expired and acked */ ... mutex_exit(&sc->sc_lock); } callout_ack(c) Clears the INVOKING state in the callout handle c. This is used in situations where it is necessary to protect against the race condition described under callout_invoking().
CONCURRENCY
The callout facility performs locking internally in order to guarantee the atomicity of individual operations performed on callouts. It does not provide life cycle management of user-provided callout data struc- tures, nor does it ensure that groups of operations (multiple function calls) are performed atomically. These aspects of callout management are the responsibility of the user of the callout facility. Scheduled callouts may be active concurrently in a context different to the user of the callout facility: on another CPU, or at a different interrupt priority level or thread on the current CPU. The callout facility provides only one guarantee in this regard: any given callout will never have multiple concurrent invocations.
SEE ALSO
condvar(9), hz(9), mutex(9), softint(9), workqueue(9)
HISTORY
The callout facility was implemented for FreeBSD by Artur Grabowski and Thomas Nordin, based on the paper by G. Varghese and A. Lauck, "Hashed and Hierarchical Timing Wheels: Data Structures for the Efficient Implementation of a Timer Facility", Proceedings of the 11th ACM Annual Symposium on Operating System Principles, ACM, https://doi.org/10.1145/37499.37504, pp. 25-38, November 1987. It was adapted to the NetBSD kernel by Jason R. Thorpe. NetBSD 11.99 January 12, 2020 NetBSD 11.99
Powered by man-cgi (2026-04-06). Maintained for NetBSD by Kimmo Suominen. Based on man-cgi by Panagiotis Christias.