Handling Interrupt in C++

Question

Hi all:

I am writing a framework for an embedded device which has the ability to run multiple applications. When switching between apps how can I ensure that the state of my current application is cleaned up correctly? For example, say I am running through an intensive loop in one application and a request is made to run a second app while that loop has not yet finished. I cannot delete the object containing the loop until the loop has finished, yet I am unsure how to ensure the looping object is in a state ready to be deleted. Do I need some kind of polling mechanism or event callback which notifies me when it has completed?

Thanks.

Answer 1

Usually if you need to do this type of thing you'll have an OS/RTOS that can handle the multiple tasks (even if the OS is a simple homebrew type thing).

If you don't already have an RTOS, you may want to look into one (there are hundreds available) or look into incorporating something simple like protothreads: http://www.sics.se/~adam/pt/

Answer 2

So you have two threads: one running the kernel and one running the app? You will need to make a function in your kernel say ReadyToYield() that the application can call when it's happy for you to close it down. ReadyToYield() would flag the kernel thread to give it the good news and then sit and wait until the kernel thread decides what to do. It might look something like this:

volatile bool appWaitingOnKernel = false;
volatile bool continueWaitingForKernel;

On the app thread call:

void ReadyToYield(void)
{
    continueWaitingForKernel = true;
    appWaitingOnKernel = true;
    while(continueWaitingForKernel == true);
}

On the kernel thread call:

void CheckForWaitingApp(void)
{
    if(appWaitingOnKernel == true)
    {
        appWaitingOnKernel = false;

        if(needToDeleteApp)
            DeleteApp();
        else
            continueWaitingForKernel = false;
    }
}

Obviously, the actual implementation here depends on the underlying O/S but this is the gist.

John.

Answer 3

(1) You need to write thread-safe code. This is not specific to embedded systems.

(2) You need to save state away when you do a context switch.