richard_damon wrote on Monday, March 12, 2012:
It takes very little time for the idle task to do its job, as it just repeatedly checks a list of tasks that need to be cleaned up, and do releases the memory for them. Of course the big issue is you need to make sure that no other tasks startup instead and use the time up. If you have enough space on the heap, you might not even need to wait, just grab the extra space and when the system is idle it will reclaim the space. One option is to just attempt to create the task, and if you get an error wait for 1-2 ticks and try again (repeatedly), hoping that eventually the idle task will get its chance to do the clean up and release the memory.
On a second note, deleting a task and then recreating it is not a normal sort of operation. Normally it is better to just write the task to just go back and wait for instructions to start again. Be aware that deleting a task does NOT automatically return to the heap any memory allocated by that task (except the stack/tcb) or release any Semaphores owned by it, so you need to use care in deleting a task at a “random” time. The one case where I can see deleting a task is where you at different times need different numbers of worker tasks for something, so you create them as needed and when they are done, they delete themselves or notify a central controller task that they are done. Even in this case, it is often better to just create a given number of them and have them wait for work unless you need to be able to trade off heap space for task control to extra heap space to use for the tasks themselves doing their work. You just need to be VERY sure you watch for and handle out of memory conditions (if you have enough not to worry about, the thread pool works cleaner), and need to worry a bit about heap fragmenttion.