The reason why Task deletion of uCOS should not occur during ISR

Question

I'm modifying some functionalities (mainly scheduling) of uCos-ii.

And I found out that OSTaskDel function does nothing when it is called by ISR.

Though I learned some basic features of OS, I really don't understand why that should be prohibited.

All it does is withrawl from readylist and release of acquired resources like TCB or semaphores...

Is there any reason for them to be banned while handling interrupt?

Answer 1

Generally, you cannot do a few things in ISRs:

1. block on a semaphore and the like
2. block while acquiring a spin lock, if it's a single-CPU system
3. cause a page fault, that has to be resolved by the virtual memory subsystem (with virtual on-disk memory, that is)

If you do any of the above in an ISR, you'll have a deadlock.

OSTaskDel() is probably doing some of those things.

Answer 2

It is not clear from the documentation why it is prohibited in this case, but OSTaskDel() explicitly calls OS_Sched(), and in an ISR this should only happen when the outer-most nested interrupt handler exists (handled by OSIntExit()).

I don't think the following is advisable, because there may be other reasons why this is prohibited, but you could remove the:

if (OSIntNesting > 0) {
    return (OS_TASK_DEL_ISR);
}

then make the OS_Sched() call conditional as follows:

if (OSIntNesting == 0) {
    OS_Sched();
}

If this dies horribly, remember I said it was ill-advised!

This operation will extend your interrupt processing time in any case so is probably a bad idea if only for that reason.

It is a bad idea in general (not just from an ISR) to asynchronously delete another task regardless of that tasks state or resource usage. uC/OS-II provides the OSTaskDelReq() function to manage task deletion in a way that allows a task to delete itself on request and therefore be able to correctly release all its resources. Even without that, sending a request via the task's normal IPC mechanisms is usually better (and more portable).

If a task is not designed for self-deletion on demand, then you might simply use OSSuspend().