In C, the most basic way to cancel a task?

Question

I'm currently writing a time-dependant embedded systems application, specifically on an ARM Cortex M4. It has a series of tasks that happen at different frequencies, and so, we're using the ARMs SysTick timer to keep track of time within a 1 second frame. A main busy loop waits until the timer has incremented and starts a task, as so:

void main(){
 while(1){
  if(!timerTicked)
     continue; //timer hasn't updated since last loop, do nothing. 
  if(time==0)
    toggleStatusLED();
  if(time==0 || time==500){
    twoHzTask(); //some task that must run twice a second
  }
  if(time%300==5){ //run at ms=5, 305 and 605
    threeHzTask();  //some task that must run three times a second
  }
 }
}

void SysTick_increment(){ //Interrupt Service Routine for SysTick timer
 time=(time+1)%1000;
}

This works perfectly for high-priority tasks that can't hang. In addition, high-priority tasks are allowed to take as long as they need to complete, however going over time may cause the system to go into fail-safe, depending on the task. However, I'd like to add a simple mechanism to abort non-mission-critical code that takes too long, like this:

void main(){
 while(1){
  if(time==500){ //run at ms=500
   savingWorld=1;
   saveTheWorld();  //super important task
   savingWorld=0;
  }
  else if(time==750){
   spinningWheels=1;
   spinWheels(); //not very important task. Code for this function is immutable, can not alter it to support task cancellation. 
   spinningWheels=0;
  }
 }
}

void SysTick_increment(){ //Interrupt Service Routine for SysTick timer
 time=(time+1)%1000;
 if(time==900 && spinningWheels){
  spinningWheels_cancel(); //we have more important stuff to do 
 }
}

As this is a basic embedded system I'd prefer not to introduce the complexity of an operating system or a multithreading mechanism. In addition, the rest of the system should be in a stable state after spinningWheels_cancel() is called. That is to say, saveTheWorld() should still work as expected. What's the simplest way to accomplish this?

Answer 1

You've implemented a collection of cooperative tasks. A key attribute of this mechanism is that multitasking only works if all tasks follow the rules and do not overrun their slots. One way to guarantee that is to break the implementation of a long, slow, low-priority task such as your spinningWheels() into segments that each meet the time constraint.

Then spinningWheels() would use private state variables to remember where it left off and continue spinning for a time. Depending on its nature, that might be a tuned number of iterations of an inner loop, or it might mean sampling time and giving up when it is too big.

In embedded systems I've built, I often end up implementing similar long-running tasks with a finite state machine that is called periodically. That is often a good fit to implementation of communications protocols which often need to be resilient in the face of unexpected delays from the other end of a wire.

Given only cooperative tasks, consider what your proposed function spinningWheels_cancel() would have to be. It is called from the timer tick interrupt, so it is limited to functions known to be reentrant. Since you don't have a formal scheduler and separate tasks, it cannot actually "kill" a task. So its implementation can only set an atomic flag that is tested by all inner loops in spinningWheels() and used to signal an early exit.

Alternatively, this requirement could be the motivation to move to some RTOS kernel. With preemptive scheduling, the slow task would overrun its time slot, but would naturally be lower priority than the more important tasks and as long as there are enough total cycles available to complete its work on average that overrun might not be so important.

There are quite a few RTOS kernels in the wild that are light weight, provide for preemptive scheduling, and supported on ARM. Both commercial (with a wide range of licensing models) and free candidates are out there, but expect the selection process to be non-trivial.

Answer 2

I think an RTOS scheduler would introduce simplicity rather than introduce complexity (one you have it running on your target that is). Independent concurrently schedulable tasks can enhance cohesion and reduce coupling - both desirable aims in any system.

However an alternative architecture is to change all your "tasks" from run-to-task-completion to state-machines that can be called repeatedly and handle their own timing and perform only a part of a task in each call, maintaining "state" to determine what should be done and avoiding "busy waits".

If you run your system tick much faster, and rather than calling your "tasks" at the required time, you simply call them as fast as possible in the main loop, and make them individually responsible for their triggering time or state switching, that gives you far greater flexibility and allows your processor to be doing something useful as "background tasks" rather than just waiting for a one-second tick. That is a far more efficient use of the processor, gives greater responsiveness, and allows work to be done asynchronously to some arbitrary time tick.

For example, based on your outline, but perhaps somewhat contrived for the purposes of illustration and due to lack of information:

#include <stdio.h>

#define TICKS_PER_SECOND = 100u ;  // for example
volatile uint32_t tick ;

void SysTick_increment()
{ 
     tick++ ;
}

void main()
{
    for(;;)
    {
        LedUpdate() ;
        TwoHzTask() ;
        ThreeHzTask() ;
        SpinningWheels() ;
    }
 }

 void LedUpdate()
 {
     static uint32_t last_event_timestamp = tick ;
     uint32_t now = tick ;

     if( now - last_event_timestamp >= TICKS_PER_SECOND )
     {
        last_event_timestamp = now ;
        toggleStatusLED() ;
     }
 }

void TwoHzTask()
{
     static uint32_t last_event_timestamp = tick ;
     uint32_t now = tick ;

     if( now - last_event_timestamp >= 2 * TICKS_PER_SECOND )
     {
        last_event_timestamp = now ;
        // Do 2Hz task...
     }
}

void ThreeHzTask()
{
     static uint32_t last_event_timestamp = tick ;
     uint32_t now = tick ;

     if( now - last_event_timestamp >= 3 * TICKS_PER_SECOND )
     {
        last_event_timestamp = now ;
        // Do 3Hz task...
     }
}

void SpinningWheels()
{
    static enum
    {
        IDLE, SPINNING;
    } state = IDLE ;

    switch( state )
    {
        case IDLE ;
        {
            if( startSpinning() )
            {
                state = SPINNING ;
            }
        } 
        break ;

        case SPINNING ;
        {
            bool keep_spinning = doOneSpin() ;
            if( !keep_spinning )
            {
                state = IDLE ;
            }
        } 
        break ;
    }
}

The important thing to note is that none of the four "task" functions is dependent on the others to determine when or whether they run except for the fact that a "well behaved" task will not block in order to wait for any event - it simply sets its state to indicate that it is waiting for that event, and switched state and/or performs some action when that event occurs. A "task" must not busy-wait or perform any lengthy processing that will not meat the real-time requirements of other tasks. So for example if you might have a length or non-deterministic loop, you would re-factor that to be in an "iteration state", where one iteration is performed per call (like the doOneSpin() function in the example above).

Note that in your original systick, the expression time=(time+1)%1000 is a really bad idea and should be avoided. It makes handling the wrap-around of time problematic if you force it to wrap every 1000 ticks. Ideally it should wrap a some power of 2, and since all integer types have a power of two range in any case, you can simply increment it as I have done. If you do that the expressions such as now - last_event_timestamp give the correct time difference even when the counter has wrapped around (so long as it has not wrapped around twice in that time), for example 1 - 999 will give the answer -998 (or 4294966298 if unsigned), whereas 1 - 0xffffffff = 2.

Another reason to avoid the expression in the ISR is that the % operator has an implicit divide operation which is relatively expensive and takes a variable number of clock cycles. We are talking tiny amounts of time of course, but in some hard real-time applications the jitter caused may be undesirable.