Re: Kernel MS Precision

Michael Rosen

However, having timeouts as int32_t instead of uint32_t, there is nothing
preventing us from using negative values to represent other units if we want
to, in a backwards-compatible way. The only negative value currently is
K_FOREVER (0xffffffff). So, if we wanted to implement better granularity, we
could allow for a higher-rate system clock and add macros to the API like,

#define US_TIMEOUT(us) \
(int32_t)((((uint32_t)(us)) & 0x3fffffff) | 0x80000000)
// ^^^^^^^^^^^^^^^^^^^^^^^^
// keep the two upper bits as control bits just in
// case '10' would mean 'microseconds', '11' could
// mean something else

rc = sem_take(&my_sem, US_TIMEOUT(500));

and have the kernel timeout code decode this as the number of ticks
corresponding to 500us.

This is of course not implemented, but should be somewhat easy to do.
While Im not sure Im 100% convinced, having negative numbers just be the number in ticks as it was in the old API should be fine. Im curious though why you went for ns when most system wouldn't be able to handle sub microsecond ticks; is there actually support for sub-tick timeouts/timers?

Though at the same time, if users are expected to use the macros, why change it away from ticks at all? And if they aren't, why have the K_MSEC macro at all? If ticks are the most precise unit you can use for timers/timeouts and ticks are user configurable, why hold the API rigid to ms? Sorry I didn't jump on this topic when you were doing the redesign or I would have contributed this perspective then :(


Join to automatically receive all group messages.