BoraAtSamraksh
commented
7 years ago In order to overcome this, c169ed6fbf54bcf29b25c0a640783c05bb5f10e1 adds a design based on a derivated class from HAL_CONTINUATION that has its own callback function that also clears up the array location. On the insertion side, we probably need mutexes which I could not find. However, it is not too much of problem since timers insertion routine cannot interrupt one another.
ChrisAtSamraksh
We might potentially have a problem with the way we are storing continuations within the virtual timers.
The current design keeps the continuations inside an array. Internally each continuation can be part of a linked list using its internal prev and next pointers. MF uses this linked list as the basis to decide what to fire next. During the firing routine, the first continuation in the linked list is dequeued and fired.
Inside the virtual timer, we decide whether an array element is available to store a continuation based on whether it is linked or not. However, before before initiating the processing of the timers the IRQ lock is removed. If a timer fires at this point, it would see the array location being unlinked and hence will overwrite its continuation target (function pointer and the arguments) to that location.
Hence (i) the previous timer callback can be missed and never gets executed, (ii) The FIFO order of the continuation queue is not followed.