Dear Reinhard Meyer,
In message 4D3C0271.4070306@emk-elektronik.de you wrote:
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):
u32 timeout = timeout_init(100); /* 100ms timeout */
do {...} while (!timed_out(timeout));
I dislike this approach. I immediately fear the same problem I just saw (incorrectly) in Albert's proposal - timeout_init() seems to store the timeouut information in some internal varoable, which is then checked by timed_out() - this is bound to fail as soon as somebody atttempts to nest timeouts.
Your implementation may be different, but you can bet sooner or later comes up with such a bugy implementation.
And it is not needed.
PLease see my proposal: we do not needs several timer or timeout related functions, all we need is a plain "get timer" function, without any arguments. And the resulting code makes it obvious to the reader that such loops can be nested as you like.
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.
I have no idea what "fast_tick" versus "tick" means here, nor why we would need more than one tick.
Best regards,
Wolfgang Denk