module Timing_wheel_intf:sig..end
A timing wheel is a data structure that maintains a clock with the current time and a
set of alarms scheduled to fire in the future. One can add and remove alarms, and
advance the clock to cause alarms to fire. There is nothing asynchronous about a
timing wheel. Alarms only fire in response to an advance_clock call.
When one creates a timing wheel, one supplies an initial time, start, and an
alarm_precision. The timing wheel breaks all time from start onwards into
half-open intervals of size alarm_precision, with the bottom half of each interval
closed, and the top half open. Alarms in the same interval fire in the same call to
advance_clock, as soon as now t is greater than all the times in the interval.
When an alarm a fires on a timing wheel t, the implementation guarantees that:
Alarm.at a < now t
That is, alarms never fire early. Furthermore, the implementation guarantees that
alarms don't go off too late. More precisely, for all alarms a in t:
interval_start t (Alarm.at a) >= interval_start t (now t)
This implies that for all alarms a in t:
Alarm.at a >= now t - alarm_precision t
One would like to have the strict inequality, Alarm.at a > now t - alarm_precision
t, but that does not hold due to floating-point imprecision.
Of course, an advance_clock call can advance the clock to an arbitrary time in the
future, and thus alarms may fire at a clock time arbitrarily far beyond the time for
which they were set. But the implementation has no control over the times supplied to
advance_clock; it can only guarantee that alarms will fire when advance_clock is
called with a time at least alarm_precision greater than their scheduled time.
start onwards are numbered 0, 1, 2, etc. Each time is
stored in the priority queue with the key of its interval number. Thus all alarms
with a time in the same interval get the same key, and hence fire at the same time.
More specifically, an alarm is fired when the clock reaches or passes the time at the
start of the next interval.
The priority queue is implemented with an array of levels of decreasing precision, with the lowest level having the most precision and storing the closest upcoming alarms, while the highest level has the least precision and stores the alarms farthest in the future. As time increases, the timing wheel does a lazy radix sort of the alarm keys.
This implementation makes add_alarm and remove_alarm constant time, while
advance_clock takes time proportional to the amount of time the clock is advanced.
With a sufficient number of alarms, this is more efficient than a log(N) heap
implementation of a priority queue.
t can only handle a (typically large) bounded range of times as
determined by the current time, now t, and the level_bits and alarm_precision
arguments supplied to create. Various functions raise if they are supplied a time
smaller than now t or >= alarm_upper_bound t. This situation likely indicates a
misconfiguration of the level_bits and/or alarm_precision. Here are some examples
of the duration alarm_upper_bound t - now t for 32-bit and 64-bit machines using the
default level_bits.
| word size | # intervals | alarm_precision | duration |
|-----------+-------------+-----------------+----------|
| 32 | 2^29 | millisecond | 7 days |
| 64 | 2^61 | nanosecond | 73 years |
val __pa_ounit_275876e34cf609db118f3d84b799a790 : string
A timing wheel is a data structure that maintains a clock with the current time and a
set of alarms scheduled to fire in the future. One can add and remove alarms, and
advance the clock to cause alarms to fire. There is nothing asynchronous about a
timing wheel. Alarms only fire in response to an advance_clock call.
When one creates a timing wheel, one supplies an initial time, start, and an
alarm_precision. The timing wheel breaks all time from start onwards into
half-open intervals of size alarm_precision, with the bottom half of each interval
closed, and the top half open. Alarms in the same interval fire in the same call to
advance_clock, as soon as now t is greater than all the times in the interval.
When an alarm a fires on a timing wheel t, the implementation guarantees that:
Alarm.at a < now t
That is, alarms never fire early. Furthermore, the implementation guarantees that
alarms don't go off too late. More precisely, for all alarms a in t:
interval_start t (Alarm.at a) >= interval_start t (now t)
This implies that for all alarms a in t:
Alarm.at a >= now t - alarm_precision t
One would like to have the strict inequality, Alarm.at a > now t - alarm_precision
t, but that does not hold due to floating-point imprecision.
Of course, an advance_clock call can advance the clock to an arbitrary time in the
future, and thus alarms may fire at a clock time arbitrarily far beyond the time for
which they were set. But the implementation has no control over the times supplied to
advance_clock; it can only guarantee that alarms will fire when advance_clock is
called with a time at least alarm_precision greater than their scheduled time.
start onwards are numbered 0, 1, 2, etc. Each time is
stored in the priority queue with the key of its interval number. Thus all alarms
with a time in the same interval get the same key, and hence fire at the same time.
More specifically, an alarm is fired when the clock reaches or passes the time at the
start of the next interval.
The priority queue is implemented with an array of levels of decreasing precision, with the lowest level having the most precision and storing the closest upcoming alarms, while the highest level has the least precision and stores the alarms farthest in the future. As time increases, the timing wheel does a lazy radix sort of the alarm keys.
This implementation makes add_alarm and remove_alarm constant time, while
advance_clock takes time proportional to the amount of time the clock is advanced.
With a sufficient number of alarms, this is more efficient than a log(N) heap
implementation of a priority queue.
t can only handle a (typically large) bounded range of times as
determined by the current time, now t, and the level_bits and alarm_precision
arguments supplied to create. Various functions raise if they are supplied a time
smaller than now t or >= alarm_upper_bound t. This situation likely indicates a
misconfiguration of the level_bits and/or alarm_precision. Here are some examples
of the duration alarm_upper_bound t - now t for 32-bit and 64-bit machines using the
default level_bits.
| word size | # intervals | alarm_precision | duration |
|-----------+-------------+-----------------+----------|
| 32 | 2^29 | millisecond | 7 days |
| 64 | 2^61 | nanosecond | 73 years |
module Time:sig..end
module type S =sig..end
module type Timing_wheel =sig..end
A timing wheel is a data structure that maintains a clock with the current time and a
set of alarms scheduled to fire in the future. One can add and remove alarms, and
advance the clock to cause alarms to fire. There is nothing asynchronous about a
timing wheel. Alarms only fire in response to an advance_clock call.
When one creates a timing wheel, one supplies an initial time, start, and an
alarm_precision. The timing wheel breaks all time from start onwards into
half-open intervals of size alarm_precision, with the bottom half of each interval
closed, and the top half open. Alarms in the same interval fire in the same call to
advance_clock, as soon as now t is greater than all the times in the interval.
When an alarm a fires on a timing wheel t, the implementation guarantees that:
Alarm.at a < now t
That is, alarms never fire early. Furthermore, the implementation guarantees that
alarms don't go off too late. More precisely, for all alarms a in t:
interval_start t (Alarm.at a) >= interval_start t (now t)
This implies that for all alarms a in t:
Alarm.at a >= now t - alarm_precision t
One would like to have the strict inequality, Alarm.at a > now t - alarm_precision
t, but that does not hold due to floating-point imprecision.
Of course, an advance_clock call can advance the clock to an arbitrary time in the
future, and thus alarms may fire at a clock time arbitrarily far beyond the time for
which they were set. But the implementation has no control over the times supplied to
advance_clock; it can only guarantee that alarms will fire when advance_clock is
called with a time at least alarm_precision greater than their scheduled time.
start onwards are numbered 0, 1, 2, etc. Each time is
stored in the priority queue with the key of its interval number. Thus all alarms
with a time in the same interval get the same key, and hence fire at the same time.
More specifically, an alarm is fired when the clock reaches or passes the time at the
start of the next interval.
The priority queue is implemented with an array of levels of decreasing precision, with the lowest level having the most precision and storing the closest upcoming alarms, while the highest level has the least precision and stores the alarms farthest in the future. As time increases, the timing wheel does a lazy radix sort of the alarm keys.
This implementation makes add_alarm and remove_alarm constant time, while
advance_clock takes time proportional to the amount of time the clock is advanced.
With a sufficient number of alarms, this is more efficient than a log(N) heap
implementation of a priority queue.
t can only handle a (typically large) bounded range of times as
determined by the current time, now t, and the level_bits and alarm_precision
arguments supplied to create. Various functions raise if they are supplied a time
smaller than now t or >= alarm_upper_bound t. This situation likely indicates a
misconfiguration of the level_bits and/or alarm_precision. Here are some examples
of the duration alarm_upper_bound t - now t for 32-bit and 64-bit machines using the
default level_bits.
| word size | # intervals | alarm_precision | duration |
|-----------+-------------+-----------------+----------|
| 32 | 2^29 | millisecond | 7 days |
| 64 | 2^61 | nanosecond | 73 years |
Alarm functions, one must supply the timing wheel that the alarm was
added to. It is an error to supply a different timing wheel.i is an
array of length 2^b_i, where the b_i are the "level bits" specified via
Level_bits.create_exn [b_0, b_1; ...].
A timing wheel can handle approximately 2 ** num_bits t intervals/keys beyond
the current minimum time/key, where num_bits t = b_0 + b_1 + ....
One can use a Level_bits.t to trade off run time and space usage of a timing
wheel. For a fixed num_bits, as the number of levels increases, the length of
the levels decreases and the timing wheel uses less space, but the constant factor
for the running time of add and increase_min_allowed_key increases.
In create_exn bits, it is an error if any of the b_i in bits has b_i <= 0,
or if the sum of the b_i in bits is greater than max_num_bits.
default returns the default value of level_bits used by Timing_wheel.create
and Timing_wheel.Priority_queue.create. It varies based on the machine's word
size. Here are the the values and the amount of space used for the level arrays.
| word | bits used | level_bits | space used |
|------+-----------+--------------------------+-------------|
| 32 | 29 | 10; 10; 9 | < 4k words |
| 64 | 61 | 11; 10; 10; 10; 10; 10 | < 10k words |
num_bits t is the sum of the b_i in t.
durations t ~alarm_precision returns the durations of the levels in t,
assuming that each interval has duration alarm_precision.
create ~start ~alarm_precision ~dummy () creates a new timing wheel with current
time start. The dummy value is a performance optimization; it would be a bug if
the timing wheel ever returned the dummy value to client code.
For a fixed level_bits, a smaller (i.e. more precise) alarm_precision decreases
the representable range of times/keys and increases the constant factor for
advance_clock.
create raises if alarm_precision <= 0.
Accessors
One can think of a timing wheel as a set of alarms. Here are various container
functions along those lines.
interval_start t time returns the time at the start of the half-open interval
containing time, i.e. the largest time less than or equal to time that is of the
form start t + k * alarm_precision t. interval_start raises if time < start t
or time is too far in the future to represent.
advance_clock t ~to_ ~handle_fired advances t's clock to to_. It fires and
removes all alarms a in t with Time.(<) (Alarm.at a) (interval_start t to_)
applying handle_fired to each such a.
If to_ <= now t, then advance_clock does nothing.
advance_clock fails if to_ is too far in the future to represent.
Behavior is unspecified if handle_fired accesses t in any way other than
Alarm functions.
alarm_upper_bound t returns the upper bound on an at that can be supplied to
add. alarm_upper_bound t is not constant; its value increases as now t
increases.
add t ~at a adds a new value a to t and returns an alarm that can later be
supplied to remove the alarm from t. add raises if at < now t || at >=
alarm_upper_bound t.
remove t alarm removes alarm from t. It is an error to remove an alarm
that is not in t.
next_alarm_fires_at t returns the minimum time to which the clock can be advanced
such that an alarm will fire, or None if t has no alarms. If
next_alarm_fires_at t = Some next, then for the minimum alarm time min that
occurs in t, it is guaranteed that: next - alarm_precision t <= min < next.
Timing wheel is implemented as a priority queue in which the keys are
non-negative integers corresponding to the intervals of time. The priority queue is
unlike a typical priority queue in that rather than having a "delete min" operation,
it has a nondecreasing minimum allowed key, which corresponds to the current time,
and an increase_min_allowed_key operation, which implements advance_clock.
increase_min_allowed_key as a side effect removes all elements from the timing
wheel whose key is smaller than the new minimum, which implements firing the alarms
whose time has expired.
Adding elements to and removing elements from a timing wheel takes constant time,
unlike a heap-based priority queue which takes log(N), where N is the number of
elements in the heap. increase_min_allowed_key takes time proportional to the
amount of increase in the min-allowed key, as compared to log(N) for a heap. It is
these performance differences that motivate the existence of timing wheels and make
them a good choice for maintaing a set of alarms. With a timing wheel, one can
support any number of alarms paying constant overhead per alarm, while paying a
small constant overhead per unit of time passed.
As the minimum allowed key increases, the timing wheel does a lazy radix sort of the
element keys, with level 0 handling the least significant b_0 bits in a key, and
each subsequent level i handling the next most significant b_i bits. The levels
hold increasingly larger ranges of keys, where the union of all the levels can hold
any key from min_allowed_key t to max_allowed_key t. When a key is added to the
timing wheel, it is added at the lowest possible level that can store the key. As
the minimum allowed key increases, timing-wheel elements move down levels until they
reach level 0, and then are eventually removed.
An Elt.t represents an element that was added to a timing wheel.
create ?level_bits ~dummy () creates a new empty timing wheel, t, with length
t = 0 and min_allowed_key t = 0.
dummy is a dummy value that will never be returned by any operation, but that
allows the implementation to be more efficient.
length t returns the number of elements in the timing wheel.
is_empty t is length t = 0
To avoid issues with arithmetic overflow, the implementation restricts keys to
being between 0 and max_representable_key, where:
max_representable_key = 1 lsl Level_bits.max_num_bits - 1
This is different from max_allowed_key t, which gives the maximum key that can
currently be stored in t. The maximum allowed key is never larger than the
maximum representable key, but may be smaller.
min_allowed_key t is the minimum key that can be stored in t. This only
indicates the possibility; there need not be an element elt in t with Elt.key
elt = min_allowed_key t. This is not the same as the "min_key" operation in a
typical priority queue.
min_allowed_key t can increase over time, via calls to
increase_min_allowed_key. It is guaranteed that min_allowed_key t <=
max_representable_key.
max_allowed_key t is the maximum allowed key that can be stored in t. As
min_allowed_key increases, so does max_allowed_key; however it is not the case
that max_allowed_key t - min_allowed_key t is a constant. It is guaranteed that
max_allowed_key t >= min (max_representable_key, min_allowed_key t + 2^B - 1,
where B is the sum of the b_i in level_bits. It is also guaranteed that
max_allowed_key t <= max_representable_key.
min_elt t returns an element in t that has the minimum key, if t is
nonempty. min_elt takes time proportional to the size of the timing-wheel data
structure in the worst case. It is implemented via a linear search.
min_key t returns the key of min_elt t, if any.
add t ~key value adds a new value to t and returns an element that can later
be supplied to remove the element from t. add raises if key <
min_allowed_key t || key > max_allowed_key t.
remove t elt removes elt from t. It is an error if elt is not currently
in t, and this error may or may not be detected.
increase_min_allowed_key t ~key ~handle_removed increases the minimum allowed
key in t to key, and removes all elements with keys less than key, applying
handle_removed to each element that is removed. If key <= min_allowed_key t,
then increase_min_allowed_key does nothing. Otherwise, if
increase_min_allowed_key returns successfully, min_allowed_key t = key.
increase_min_allowed_key raises if key > max_representable_key.
increase_min_allowed_key takes time proportional to key - min_allowed_key t,
although possibly less time.
Behavior is unspecified if handle_removed accesses t in any way other than
Elt functions.