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.