• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 98 subscribers
  • Views 386 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Any potential downfalls with repeated task creation and deletion?

SQ
Prodigy 170 points

Dear DSP/BIOS experts,

My team is using BIOS version 5.33.06 with code gen tools version 6.1.14 on the C6748 DSP.  In our application we have a long-running process (on the order of 20 seconds or more) that sometimes needs to be preemptively aborted.  The scenario here is when some outside entity (i.e. a "host") sends the DSP an abort command, our compute-intensive signal-processing function (which uses no dynamic memory allocation) needs to immediately end and cede control back to the calling function who will repond back to the host.  This is an asynchronous event and after it occurs, the signal-processing cannot simply resume where it left off and has to "rewind" itself.

Our current solution is to set a global abort flag which the signal-processing function checks after every long-running mathematical operation and short-circuits itself in the event that the abort flag goes high.  While perfectly functional, we don't like this solution for a number of reasons.

A more elegant design that we had in mind entails spawning a new BIOS task via TSK_create() each time we run this signal-processing.  Then if we happen to receive the abort command a task with higher priority (the one listening to the host) will suspend the signal-processing thread and then kill it.

The question we have is are there any known issues with DSP/BIOS regarding the repeated spawning and then destruction of tasks?  This would be just a single task that would potentially be created and then destroyed many hundreds of thousands of times, so we don't think it would present a problem for the kernel but we thought we'd ask nonetheless.  Note that TSK_delete() would of course be called and the signal-processing task wouldn't own any DSP/BIOS resources.

Thanks,

Shehrzad 

  • 0
    TI__Mastermind 30830 points

    The only issue with your idea is the potential memory fragmentation resulting from the repeated MEM_alloc and MEM_free calls associated with TSK_create() and TSK_delete().

    You can minimize and possibly eliminate this problem if:

    a) Your application has no HOOKS defined (ie storage for hook function pointers is allocated during TSK_create(), and freed during TSK_delete())

    b) The stack used by the dynamically created TSK is provided to TSK_create() (by passing a pointer to a static stack buffer to TSK_create()).

    c) Your application isn't allocating and freeing memory for anything else at this point in its execution (ie no other dynamic object create/delete, nor MEM_alloc/free calls).

    If the above 3 conditions are met, then the only memory operations occurring will be the allocation and freeing of a TSK object, which should re-use the same block of memory indefinitely.

    Alan