Codecov Report

Merging #303 (f2ed318) into main (a31018d) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #303   +/-   ##
=======================================
  Coverage   90.60%   90.60%           
=======================================
  Files           3        3           
  Lines         532      532           
  Branches      142      142           
=======================================
  Hits          482      482           
  Misses         14       14           
  Partials       36       36           

Flags with carried forward coverage won't be shown. Click here to find out more.

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a31018d...f2ed318. Read the comment docs.

Preferred solution would be that timer.c will check that timer was already deleted

This is not an easy thing to do because the memory used by the timer's structures is freed so could contain anything after the timer has been deleted. Even in the case of a timer being allocated statically, the statically allocated memory may be re-used to create another timer.

There is an analogous problem with tasks. Kernel aware debuggers that display tasks had no idea if a task had been deleted and re-created since it last viewed the memory. In that situation we added a unique number to each task structure. If the kernel aware debugger saw a task structure (TCB) occupying the same memory location but with a different unique number it knows its a different task even if the task name and handle are the same (the handle just being a pointer to the TCB). I was wondering if we could do something similar with timers. If a timer is recognised from a combination of its handle and unique number contained within its structure - then a command operating on a timer that had a different unique number to that expected could be discarded.

We could consider that in those cases the error is on the part of the application writer as they are sending a command to a timer they know they have already deleted, whereas the autoreload event is a special case because it happens automatically. That would seem reasonable.

Agreed.

Can we think of any other cases that need to same treatment (sending to the front)?

No, but let me fix this up a little bit to prompt developers in the future to consider any new command for sending to front. It would be too easy with the code as is for a developer not to consider the question.

My first thought is to set a bit in each command value as a tag, either tmrCMD_GROUP_FROM_ISR, tmrCMD_GROUP_PRIORITY, tmrCMD_GROUP_STANDARD. Then xTimerGenericCommand() would use those bits to determine whether to call xQueueSendToBackFromISR(), xQueueSendToFront(), or xQueueSendToBack(). It currently uses xCommandID < tmrFIRST_FROM_ISR_COMMAND to make the determination.

Seems a good solution, and simpler that those I was contemplating.

You might have been right contemplating other solutions. Please see #305 for what I think is a better solution. Let me know which way you'd like to go. This solution (this PR, #303) does have the advantage of having fewer changes to the code. But it's awkward in its operation and not as clean in its design as the rest of FreeRTOS code. So sorry if you've wasted time on my waffling.

Note also that in #305 I fixed a couple of other issues. Will gladly fix (or not fix) them here in this PR as you prefer.

Closing this PR since #305 was better.