In this section, we describe the scheduling mechanisms used by ALMOS-MKH.

A. Threads List

There are two lists of threads in ALMOS-MKH: a list of user threads and a list of kernel threads.

B. Context Switches

ALMOS-MKH supports switching context among threads only when they do not hold any kernel locks.

Context switches have two causes:

• The currently-executing thread explicitly asks to be rescheduled. When such a thing happens, it is guaranteed that the current thread does not hold any kernel locks.
• A rescheduling interrupt (such as a tick) was received and it is decided that another thread needs to execute. The mechanism to ensure that the currently-executing thread does not hold any kernel locks is more complex, and described below.

When a rescheduling interrupt is received, the interrupt routine that is called gives a look at the currently-executing thread. If this thread does not hold any kernel locks, the rescheduling is performed right away. Otherwise, the interrupt routine adds a flag in the thread's structure, to indicate that a rescheduling is necessary. The interrupt routine then returns to the original context.

The thread keeps executing, and at some point, will release its last lock. When this last release is performed, the thread will give a look at the rescheduling flag in its structure. If this flag is set, the thread performs the rescheduling itself: this behavior is the same as if it was the thread that had asked to be rescheduled in the first place. In this scenario, it is therefore guaranteed that no kernel locks are held.

C. Kernel Mode Preemption

ALMOS-MKH supports descheduling a userland thread that is currently in kernel mode - as a result of a syscall for example.