eCosTM Reference Manual
Prev |  | Next

# Chapter 1. eCos kernel overview

This is an overview of the internal workings of the eCosTM kernel.

# The scheduler

At the core of the kernel is the scheduler. This defines the way in which threads are run, and provides the mechanisms by which they may synchronize. It also controls the means by which interrupts affect thread execution. No single scheduler can cover all possible system configurations. For different purposes we will need to cover several scheduling polices. In this release three schedulers are provided (described in more detail in the section called Sched subdirectory in Chapter 2):

- a bitmap scheduler

- a multi-level queue scheduler

- a lottery scheduler

At present the system will only support a single scheduler at any one time. Future systems may allow multiple schedulers to co-exist, but this will be hidden behind the scheduler API in the current release.

To make scheduling safe we need a mechanism to protect the scheduler data structures from concurrent access. The traditional approach to this is to disable interrupts during the critical regions. Unfortunately this increases the maximum interrupt dispatch latency, which is to be avoided in any real-time system.

The mechanisms chosen for eCos is to maintain a counter, `Scheduler::sched_lock` that, if non-zero, prevents any rescheduling. The current thread can claim the lock by calling `Scheduler::lock()`. This increments the counter and prevents any further scheduling. The function `Scheduler::unlock()` decrements the counter and if it returns to zero, allows scheduling to continue.

For this to work in the presence of interrupts, it is necessary for the Interrupt Service Routines (ISR) to defer any scheduler-oriented operations until the lock is about to go zero. We do this by splitting the work of an ISR into two parts, with the second part, the Deferred Service Routine (DSR), being queued until the scheduler decides it is safe to run. This is covered in more detail in the section called Interrupts and the section called Interrupt and exception handlers in Chapter 3.

On a uni-processor, `Scheduler::lock()` is a simple increment of Scheduler::sched_lock. It does not need to be a read-modify-write cycle since the lock is strictly nested. The mere fact that the current thread is running implies that the lock has not been claimed by another thread, so it is always claimable.

`Scheduler::unlock()` is generic to all scheduler implementations.

Prev | Home | Next
Preliminaries | Up | Thread synchronization