Xenomai  3.0.5
Thread scheduling control
Collaboration diagram for Thread scheduling control:

Modules

 SCHED_QUOTA scheduling policy
 The SCHED_QUOTA policy enforces a limitation on the CPU consumption of threads over a globally defined period, known as the quota interval.
 

Data Structures

struct  xnsched
 Scheduling information structure. More...
 

Functions

static int xnsched_run (void)
 The rescheduling procedure. More...
 
static void xnsched_rotate (struct xnsched *sched, struct xnsched_class *sched_class, const union xnsched_policy_param *sched_param)
 Rotate a scheduler runqueue. More...
 

Detailed Description

Function Documentation

◆ xnsched_rotate()

void xnsched_rotate ( struct xnsched sched,
struct xnsched_class *  sched_class,
const union xnsched_policy_param *  sched_param 
)
inlinestatic

Rotate a scheduler runqueue.

The specified scheduling class is requested to rotate its runqueue for the given scheduler. Rotation is performed according to the scheduling parameter specified by sched_param.

Note
The nucleus supports round-robin scheduling for the members of the RT class.
Parameters
schedThe per-CPU scheduler hosting the target scheduling class.
sched_classThe scheduling class which should rotate its runqueue.
sched_paramThe scheduling parameter providing rotation information to the specified scheduling class.
Tags
unrestricted, atomic-entry

◆ xnsched_run()

int xnsched_run ( void  )
inlinestatic

The rescheduling procedure.

This is the central rescheduling routine which should be called to validate and apply changes which have previously been made to the nucleus scheduling state, such as suspending, resuming or changing the priority of threads. This call performs context switches as needed. xnsched_run() schedules out the current thread if:

  • the current thread is about to block.
  • a runnable thread from a higher priority scheduling class is waiting for the CPU.
  • the current thread does not lead the runnable threads from its own scheduling class (i.e. round-robin).

The Cobalt core implements a lazy rescheduling scheme so that most of the services affecting the threads state MUST be followed by a call to the rescheduling procedure for the new scheduling state to be applied.

In other words, multiple changes on the scheduler state can be done in a row, waking threads up, blocking others, without being immediately translated into the corresponding context switches. When all changes have been applied, xnsched_run() should be called for considering those changes, and possibly switching context.

As a notable exception to the previous principle however, every action which ends up suspending the current thread begets an implicit call to the rescheduling procedure on behalf of the blocking service.

Typically, self-suspension or sleeping on a synchronization object automatically leads to a call to the rescheduling procedure, therefore the caller does not need to explicitly issue xnsched_run() after such operations.

The rescheduling procedure always leads to a null-effect if it is called on behalf of an interrupt service routine. Any outstanding scheduler lock held by the outgoing thread will be restored when the thread is scheduled back in.

Calling this procedure with no applicable context switch pending is harmless and simply leads to a null-effect.

Returns
Non-zero is returned if a context switch actually happened, otherwise zero if the current thread was left running.
Tags
unrestricted