0

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?

FoolyCooly
  • 59
  • 1
  • 1
  • 6

2 Answers2

1

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().

Clifford
  • 88,407
  • 13
  • 85
  • 165
  • Sorry for late check! I was having Natl' holiday of my country. I think your answer was helpful already I gonna check OSTskDelReq()! Thanks for your kind answer :) – FoolyCooly Oct 04 '12 at 01:45
0

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.

Alexey Frunze
  • 61,140
  • 12
  • 83
  • 180
  • Thanks for your answer Alex. :) All it does is release of shared objects(like semaphore). I can guess why blocking(or pending) should be prohibited but not releasing. Is there any clear reason for releasing should be also banned? – FoolyCooly Sep 27 '12 at 05:10
  • I don't know all the implementation details. Look deeper. It could also be that the function originally was not designed (meant) to be called in the ISR context, even if there isn't really anything to prevent it from functioning. Personally, I wouldn't call such functions from ISRs. ISRs are for simpler stuff. – Alexey Frunze Sep 27 '12 at 05:18
  • Yes I think you're right. I think I should find some other way to do what I want. Thanks for your advice :-) – FoolyCooly Sep 27 '12 at 06:48
  • How can a thread block while acquiring a spin lock ? It should never block, it would keep on spinning. You can try to acquire a spinlock while inside a ISR. – Harman Sep 27 '12 at 19:48
  • @Harman It wasn't about a *thread* blocking, but you're right, spinning is probably a better word. You can try to acquire, correct. – Alexey Frunze Sep 27 '12 at 20:21