TSK_delete

Hey Steven,

we did some further investigations on that topic.

Assume we have 2 tasks. A control task (prio: 2) and a working task (prio: 1). The algorithm in the working task is a quite complex lib call, so we do not have the possibility to call TSK_exit().

If a timeout occurs the task need to be deleted by the control task. Due to RTS lib calls it is possible that the working task hold a RTS resource mutex so after the call to delete the mutex will never be released (as mentioned in BIOS API Guide).

So the idea is to get the lock on that mutex before deleting the task. I call:

__TI_resource_lock(__TI_LOCK_MAX);
__TI_resource_unlock(__TI_LOCK_MAX);

in the task delete hook. This seems to work hence the working task wont relock the mutex cause task priority is lower. Inside the RTS lib there are more than on resources to be locked. 

Is it enough to lock/unlock only one of them or should I do the same with all resources?

So is this is a save way to delete a task while running at all?

Tobias

Deleting a non-terminated task is tricky. Grabbing the RTS lock is a good first step. Can you guarantee that no other resource will be left in a bad state (e.g. Semaphore, Event, System output, Log output, etc.)

Do you know why the working task would have timed-out or are you just coding it up just in case?

Todd

Hi Todd,

thanks for reply.

ToddMullanix said:

Grabbing the RTS lock is a good first step

Am I right that behind the 5 different RTS mutex IDs is only one DSP/BIOS LCK?

ToddMullanix said:

Do you know why the working task would have timed-out or are you just coding it up just in case?

We use semaphores to trigger the working task and a queue to pass the data to be processed in the algorithm:

void tskControl(void)
{
    Object obj;

    // fill queue
    QUE_put(objectQueue, &obj);

    // start working task
    SEM_postBinary(startWorkingTaskMutex);

    TSK_yield();

    if (!SEM_pendBinary(stopWorkingTaskMutex, timeout))
    {
        deleteWorkingTask();
    }
}

void tskWorking(void)
{
    while (1)
    {
        SEM_pendBinary(startWorkingTaskMutex, SYS_FOREVER);

        Object *p;

        if ((QUE_Handle)(p = (Object*)QUE_get(objectQueue)) != objectQueue)
        {
            runAlgorithm();
        }

        SEM_postBinary(stopWorkingTaskMutex);
    }
}

I suppose that the start/stop semaphore and the queue are not left in a bad state if working task is deleted. Inside the algorithm there are only calls to std C/C++ lib. To make it little bit more interesting the algorithm uses exception handling. I already did some tests where I could caught the exception in control task. I need to think about that, but at the moment it should work in a non exceptional case.

Do we have a chance to get that save?

Tobias

Tobias Heiss said:

Am I right that behind the 5 different RTS mutex IDs is only one DSP/BIOS LCK?

Which codegen (and version) are you using?

Tobias Heiss said:

Do we have a chance to get that save?

?

Todd

We use CGT 7.4.4

What else do we have to care about deleting a non-terminated task? Are there further characteristics related to exception handling?

SYS/BIOS registers it's own RTS lock function. It is called ti_sysbios_BIOS_rtsLock (and ti_sysbios_BIOS_rtsUnlock) in the large generated .c file (Debug->configPkg->package->cfg-><appname><suffix>.c).

So if you call __TI_resource_lock(__TI_LOCK_MAX);, it ends up in ti_sysbios_BIOS_rtsLock which manages 1 gate (aka mutex).

Other concerns really are application specific if you are not making in SYS/BIOS calls in the area that could get stuck.

Todd