Helppppp on Context Switching.

Usually.

Most RTOSes (at least the ones I've seen the insides of) do their context switching from an interrupt service routine, so the processors interrupt mechanism does the "push".

Depends on the processor. Sometimes it can.

Depends on the processor. Sometimes there is.

Usually you switch the stack pointer over to point to the stack of the new thread and then do a "return from interrupt".

--
Grant Edwards                   grante             Yow!  I HAVE a towel.
                                  at               
                               visi.com

Let's say "some" event has happened and a HIGHER priority is READY.

Now a Lower priority thread (in middle of its time slice) will still not be able to continue. (Thats what shoud happen right!)

Now no there is tick interrupt...still context is switched...How?

Regards,

#define

This depends on the processor architecture, but it is normal for the PC to automatically get stored on the stack when context switching - just as with any other function (or interrupt) call. Entering the function with a branch instruction will normally automatically store the PC + offset as the return address on the stack. Exiting the function with some form or return instruction will normally automatically retrieve the return address from the stack and load it into the PC.

Take a look at the second section of

There is a detailed example.

Regards, Richard.

OK, buth there's no need to SHOUT. ;)

RTOSes don't usually use time-slices. A few have time-slicing as an optional feature, but it's often considered "bad practice" to resort to time slicing.

Right.

1) In many (most, in my experience) cases the event that made the higher priority task runnable was caused by an interrupt (e.g. I/O device or hardware timer). In that case, the context switch is done at the end of the ISR. 2) If a context switch really does need to be trigger from a user task, all of the processors I've ever used have a software interrupt mechanism.

--
Grant Edwards                   grante             Yow!  YOU PICKED KARL
                                  at               MALDEN'S NOSE!!
                               visi.com

Yes. To expand a little bit, usually when servicing an interrupt, you execute common interrupt entry and exit code. This would typically track the number of nested interrupts. When the exit routine determines that it is ready to return to task (non-interrupt) code, it checks to see if the suspended task is still active (normally a flag). If so, it simply returns to it. Otherwise, it would save the context of the current task and restore the context of the newly activated task and start it.

--
Thad

Unless the OS uses interrupt processes, in which case the context switch is done at the beginning of the ISR. And again at the end.