9,16 → 9,15 |
true for both uniprocessor as well as multiprocessor systems. In the case of |
multiprocessor systems, the activities are trully happening in parallel. The |
scheduler helps to materialize this impression by planning threads on as |
many processors as possible and, where this means reaching its limits, by |
many processors as possible and, where this means reaches its limits, by |
quickly switching among threads executing on a single processor.</para> |
|
<section> |
<title>Contexts</title> |
|
<para>The term <emphasis>context</emphasis> refers to the set of processor |
resources that define the current state of the computation or the |
environment and the kernel understands it in several more or less narrow |
sences:</para> |
<para>The term context refers to the set of processor resources that |
define the current state of the computation or the environment and the |
kernel understands it in several more or less narrow sences:</para> |
|
<itemizedlist> |
<listitem> |
108,7 → 107,7 |
<section> |
<title>Threads</title> |
|
<para>A thread is the basic executable entity with a code and a stack. |
<para>A thread is the basic executable entity with some code and stack. |
While the code, implemented by a C language function, can be shared by |
several threads, the stack is always private to each instance of the |
thread. Each thread belongs to exactly one task through which it shares |
119,18 → 118,18 |
in userspace is made by refering to the former group as to kernel threads |
and to the latter group as to userspace threads. Both kernel and userspace |
threads are visible to the scheduler and can become a subject of kernel |
preemption and thread migration anytime when preemption is not |
disabled.</para> |
preemption and thread migration during times when preemption is |
possible.</para> |
|
<formalpara> |
<title>Thread States</title> |
|
<para>In each moment, a thread exists in one of six possible thread |
states. When the thread is created and first inserted into the |
states. When the thread is created and first readied into the |
scheduler's run queues or when a thread is migrated to a new processor, |
it is put into the <constant>Entering</constant> state. After some time |
elapses, the scheduler picks up the thread and starts executing it. A |
thread being currently executed on a processor is in the |
it is put into the <constant>Entering</constant> state. After some time, |
the scheduler picks up the thread and starts executing it. A thread |
being currently executed on a processor is in the |
<constant>Running</constant> state. From there, the thread has three |
possibilities. It either runs until it is preemtped, in which case the |
state changes to <constant>Ready</constant>, goes to the |
221,7 → 220,7 |
migrated to another processor and scheduled there. In the worst case |
scenario, two execution flows would be using the same stack.</para> |
|
<para>The scheduling policy is implemented in the function |
<para>The scheduling policy is implemented in function |
<code>find_best_thread</code>. This function walks the processor run |
queues from lower towards higher indices and looks for a thread. If the |
visited run queue is empty, it simply searches the next run queue. If it |