How does a VxWorks scheduler get executed?

Question

Would like to know how the scheduler gets called so that it can switch tasks. As in even if its preemptive scheduling or round robin scheduling - the scheduler should come in to picture to do any kind of task switching. Supposing a low priority task has an infinite loop - when does the scheduler intervene and switch to a higher priority task?

Query is: 1. Who calls the scheduler? [in VxWorks] 2. If it gets called at regular intervals - how is that mechanism implemented?

Thanks in advance.

--Ashwin

Neona

While I don't know VxWorks, in other OS the scheduler is typically called by a timer interrupt, so it can switch tasks even if one task is currently busy. – Disproportionate

Answer 1

The simple answer is that vxWorks takes control through a hardware interrupt from the system timer that occurs continually at fixed intervals while the system is running.

Here's more detail:

When vxWorks starts, it configures your hardware to generate a timer interrupt every n milliseconds, where n is often 10 but completely depends on your hardware. The timer interval is generally set up by vxWorks in your Board Support Package (BSP) when it starts.

Every time the timer fires an interrupt, the system starts executing the timer interrupt handler. The timer interrupt handler is part of vxWorks, so now vxWorks has control. The first thing it does is save the CPU state (such as registers) into the Task Control Block (TCB) of the currently running task.

Then eventually vxWorks runs the scheduler to determine who runs next. To run a task, vxWorks copies the state of the task from its TCB into the machine registers, and after it does that the task has control of the CPU.

Bonus info:

vxWorks provides hooks into the task switching logic so you can have a function get called whenever your task gets preempted.

Rushing

Note that this is only true if you enable round robin scheduling (by calling kernelTimeSlice() ), the default is priority-based preemptive scheduling. – Rose

@nos: The timer interrupt is always running to keep track of tick count, watchdog timers, and semaphore timeouts regardless of scheduling policy. It just happens that for priority-based preemptive scheduling, the vxWorks scheduler does not choose a new task to run unless some timer operation moved a higher priority task to the ready queue. But fair point. I've always wanted to update this answer to be more precise and include system calls, which I completely forgot to mention at the time. – Rushing

It should also be remembered that round robin is IN ADDITION to priority based. You get priority based regardless. Round robin scheduling only affects tasks within the same priority level. In addition, even in a priority only, tasks can still use eg taskDelay, and so the system ticks still need to carryon. – Laquitalar

Answer 2

indiv provides a very good answer, but it is only partially accurate.
The actual working of the system is slightly more complex.

The scheduler can be executed as a result of either synchronous or asynchronous operations.

Synchronous refers to operations that are caused as a result of the code in the currently executing task. A prime example of this would be to take a semaphore (semTake).
If the semaphore is not available, the currently executing task will pend and no longer be available to execute. At this point, the scheduler will be invoked and determine the next task that should execute and will perform a context switch.

Asynchronous operations essentially refer to interrupts. Timer interrupts were very well described by indiv. However, a number of different elements could cause an interrupt to execute: network traffic, sensor, serial data, etc...

It is also good to remember that the timer interrupt does not necessarily cause a context switch! Yes, the interrupt will occur, and delayed task and the time slice counters will be decremented. However, if the time slice is not expired, or no higher priority task transitions from the pended to the ready state, then the scheduler will not actually be invoked, and you will return back to the original task, at the exact point where execution was interrupted.

Note that the scheduler does not have its own context; it is not a task. It is simply code that executes in whatever context it is invoked from. Either from the interrupt context (asynchronous) or from the invoking task context (synchronous).

Aldenalder

Note that the scheduler does not have its own context; it is not a task. It is simply code that executes in whatever context it is invoked from. Either from the interrupt context (asynchronous) or from the invoking task context (synchronous). This is true for MOST OSes I believe, real-time or not – Touch

Answer 3

Unless you have a majorily-customized target build, the scheduler is invoked by the Timer interrupt. Details are platform-specific, though.

Sweat

Answer 4

The scheduler also gets invoked if current task gets completed or blocks.

Ballonet