1. Home
  2. Embedded Programming
  3. ChainTask and TerminateTask in OSEK

ChainTask and TerminateTask in OSEK

Has anyone see this problem?

I have a BCC task that has to make a run-time decision to perform a ChainTask (on itself) or a TerminateTask:

... SuspendAllInterrupts(); x = global_var; ResumeAllInterrupts();

if ( x ) { ChainTask (this_task); } else { TerminateTask(); }

The problem is that there is a window of vulnerability between the ResumeAllInterrupts and the TerminateTask where an interrupt or task can preempt and write global_var (to non-zero). In which case, the task would really have wanted to ChainTask and not TerminateTask. Is there a way to make this thread-safe?

Can't use ECC tasks because they use too much stack. Can't use PostTaskHook because this is called every time this task is preempted. Can't remove ResumeAllInterrupts call because OSEK doesn't allow API calls within a critical section.

Reply to
Raul
Loading thread data ...

What happens if the event occurs after your task terminates? Is there another task to accept it or does the event become insignificant?

If the first is true, you should communicate with this other tasks by means of semaphores or similar and terminate when the other task is ready to deal with the event.

in the second case, I can't see why there is a necessity to care. You can't predict the future and need to decide at some point.

Or wouldn't it be best never to terminate, but to have some sort of state diagram. Personally I prefer the use of ever existing tasks and use termination only in rare circumstances.

Reply to
Lanarcam

Thanks for the reply.

The preempting task or interrupt will do something like the following:

... global_var = 5; ActivateTask( id_of_task_that_wants_to_chain_or_terminate ); ...

So if the event occurs after the task terminates, the ActivateTask should start the task up again to act on the new value of global_var.

Can't use infinite loop (non terminating tasks) because I may have several tasks at the same priority. The tasks need to be cooperative.

Reply to
Raul

following:

cooperative.

I don't know OSEK specifically, but there should exist some sort of event that your interrupt can post.

Your task could pend on that event instead of terminating. It won't keep the CPU busy while pending. The other tasks at same or other priorities will be able to execute their code independantly of the waiting task.

Reply to
Lanarcam

OSEK provides Event flags (and the accompanying WaitEvent) for ECC tasks only. It doesn't provide this service for BCC tasks. I'm using BCC tasks because my system can't afford the cost (excess stack) of ECC tasks. Several BCC tasks at the same priority will share a stack because they're running cooperatively.

Reply to
Raul

using

ECC

But in case when requested resources aren't available, it may lead to indeterministic behavior of the operation. This situation may occur, when too many tasks are activated. To avoid that weakness, the user is also allowed to statically assign task control blocks and stack areas for critical tasks. Such explicitly defined resources are hold by a task for the application life time. In this case the task control block and/or the task stack are not released and cannot be re-assigned for other tasks.

Couldn't you have a sort of background permanent task that will reactivate your task when the event occurs?

Reply to
Lanarcam

I was hoping there was a way to not have an active entity reactivate the task in the event that the task was preempted within this window. I was hoping for a way to close the window.

Reply to
Raul

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.