Unfortunately, there isn't a clear answer to that question. Obviously, the time to switch tasks depends on the CPU speed. If you look carefully at the code, you will also see that it depends on the depth of the stack at the time of the context switch, since the multitasker only has to copy the currently-used portion of the stack when it does the switch.

To get a ballpark idea of the time, I measured how long it took to get through the following bit of code, where the task switch takes place.

    EnableDebugPin();                           /* DEBUG DEBUG */

    SaveStack(&(stacks[currentTask->taskNumber][0]));
    currentTask->mySP = SP;

/*  Switch to the new task  */

    currentTask = rlh.nextWait;                 /* The new current task */
    rlh.nextWait = currentTask->nextWait;       /* Unlink it from READY list */
    if (currentTask->nextWait != NULL) {
        currentTask->nextWait->prevWait = &rlh;
        }
    currentTask->prevWait = NULL;               /* Unlink it completely */
    currentTask->nextWait = NULL;

/*  Restore the new task's stack and stack pointer */

    SP = currentTask->mySP;
    RestoreStack(&(stacks[currentTask->taskNumber][0]));

    DisableDebugPin();                          /* DEBUG DEBUG */

On a 22 MHz SiLabs C8051F12, I measured about 50 microseconds for most excursions through this snippet. Unfortunately, I don't know offhand what the "typical" stack depth is in this particular program.

Perhaps more important than the absolute time to switch tasks is what fraction of the total time that represents. And once again, that's an "it depends" thing. If an application is thrashing between tasks as fast as it possibly can, then the overhead may be a deal breaker. On the other hand, if the task switches occur only when a human comes along and does something, or maybe in response to some slow timer interrupt, the overhead might not be of any concern at all.

YMMV!

-- Russ