| 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 |