Hi All,
I am starting this thread to revive and, hopefully, come to a general agreement on how timers should be implemented and used in the ARM architecture, and get rid of current quick fixes. Let us start with Reinhard's proposal:
There were several suggestions about that in the past (including from me) that involve rework everywhere HZ related timeouts are used. I still prefer a method as follows (because it does not need repeated mul/div calculations nor necessarily 64 bit arithmetic):
Agreed for unnecessary mult-div, but 64-bit we would not avoid, and should not IMO, when the HW has it.
u32 timeout = timeout_init(100); /* 100ms timeout */
do {...} while (!timed_out(timeout));
Internally it would be like:
timeout_init(x): return fast_tick + (x * fast_tick_rate) / CONFIG_SYS_HZ; /* this might need 64 bit precision in some implementations */
time_out(x): return ((i32)(x - fast_tick)) < 0;
If the tick were really high speed (and then 64 bits), fast_tick could be derived by shifting the tick some bits to the right.
The only thing I slightly dislike about the overall idea is the signed rather than unsigned comparison in the timeout function (I prefer using the full 32-bit range, even if only as an academic point) and the fact that the value of the timeout is encoded in advance in the loop control variable 'timeout'.
I'd rather have a single 'time(x)' (or 'ticks_elapsed(x)', names are negotiable) macro which subtract its argument from the current ticks, e.g. 'then = time(0)' would set 'then' to the number of ticks elapsed from boot, while 'now = time(then)' would set 'now' the ticks elapsed from 'then'; and a 'ms_to_ticks(x)' (again, or 'milliseconds(x)') :
#define time(x) (ticks - x) #define ms_to_ticks(m) ( (m * fast_tick_rate) / CONFIG_SYS_HZ)
Note that time(x) assumes unsigned arguments and amounts to an unsigned compare, because we're always computing an difference time, i.e. even with x = 2 and ticks = 1, the result is correct -- that's assuming ticks is monotonous 32-bits (or 64-bits for the platforms that can support it as an atomic value)
Your example would then become
then = time(0); do {...} while ( time(then) < ms_to_ticks(100) );
... moving the actual timeout value impact from the time sample before the 'while' to the 'while' condition at then end.
For expressiveness, added macros such as:
#define now() time(0) #define ms_elapsed(then,ms) ( time(then) < ms_to_ticks(ms) )
... would allow writing the same example as:
then = now(); do {...} while ( !ms_elapsed(then,100) );
But, as long as we cannot agree on something, there will be no time spent to make patches...
Makes sense, hence this specific thread. :)
Best Regards, Reinhard
Amicalement,