Rev 133 | Rev 142 | Go to most recent revision | Show entire file | Ignore whitespace | Details | Blame | Last modification | View Log | RSS feed
Rev 133 | Rev 140 | ||
---|---|---|---|
Line 7... | Line 7... | ||
7 | <para>One of the key aims of the operating system is to create and support |
7 | <para>One of the key aims of the operating system is to create and support |
8 | the impression that several activities are executing contemporarily. This is |
8 | the impression that several activities are executing contemporarily. This is |
9 | true for both uniprocessor as well as multiprocessor systems. In the case of |
9 | true for both uniprocessor as well as multiprocessor systems. In the case of |
10 | multiprocessor systems, the activities are trully happening in parallel. The |
10 | multiprocessor systems, the activities are trully happening in parallel. The |
11 | scheduler helps to materialize this impression by planning threads on as |
11 | scheduler helps to materialize this impression by planning threads on as |
12 | many processors as possible and, where this means reaches its limits, by |
12 | many processors as possible and, where this means reaching its limits, by |
13 | quickly switching among threads executing on a single processor.</para> |
13 | quickly switching among threads executing on a single processor.</para> |
14 | 14 | ||
15 | <section> |
15 | <section> |
16 | <title>Contexts</title> |
16 | <title>Contexts</title> |
17 | 17 | ||
18 | <para>The term context refers to the set of processor resources that |
18 | <para>The term <emphasis>context</emphasis> refers to the set of processor |
19 | define the current state of the computation or the environment and the |
19 | resources that define the current state of the computation or the |
20 | kernel understands it in several more or less narrow sences:</para> |
20 | environment and the kernel understands it in several more or less narrow |
- | 21 | sences:</para> |
|
21 | 22 | ||
22 | <itemizedlist> |
23 | <itemizedlist> |
23 | <listitem> |
24 | <listitem> |
24 | <para>synchronous register context,</para> |
25 | <para>synchronous register context,</para> |
25 | </listitem> |
26 | </listitem> |
Line 105... | Line 106... | ||
105 | </section> |
106 | </section> |
106 | 107 | ||
107 | <section> |
108 | <section> |
108 | <title>Threads</title> |
109 | <title>Threads</title> |
109 | 110 | ||
110 | <para>A thread is the basic executable entity with some code and stack. |
111 | <para>A thread is the basic executable entity with a code and a stack. |
111 | While the code, implemented by a C language function, can be shared by |
112 | While the code, implemented by a C language function, can be shared by |
112 | several threads, the stack is always private to each instance of the |
113 | several threads, the stack is always private to each instance of the |
113 | thread. Each thread belongs to exactly one task through which it shares |
114 | thread. Each thread belongs to exactly one task through which it shares |
114 | address space with its sibling threads. Threads that execute purely in the |
115 | address space with its sibling threads. Threads that execute purely in the |
115 | kernel don't have any userspace memory allocated. However, when a thread |
116 | kernel don't have any userspace memory allocated. However, when a thread |
116 | has ambitions to run in userspace, it must be allocated a userspace stack. |
117 | has ambitions to run in userspace, it must be allocated a userspace stack. |
117 | The distinction between the purely kernel threads and threads running also |
118 | The distinction between the purely kernel threads and threads running also |
118 | in userspace is made by refering to the former group as to kernel threads |
119 | in userspace is made by refering to the former group as to kernel threads |
119 | and to the latter group as to userspace threads. Both kernel and userspace |
120 | and to the latter group as to userspace threads. Both kernel and userspace |
120 | threads are visible to the scheduler and can become a subject of kernel |
121 | threads are visible to the scheduler and can become a subject of kernel |
121 | preemption and thread migration during times when preemption is |
122 | preemption and thread migration anytime when preemption is not |
122 | possible.</para> |
123 | disabled.</para> |
123 | 124 | ||
124 | <formalpara> |
125 | <formalpara> |
125 | <title>Thread States</title> |
126 | <title>Thread States</title> |
126 | 127 | ||
127 | <para>In each moment, a thread exists in one of six possible thread |
128 | <para>In each moment, a thread exists in one of six possible thread |
128 | states. When the thread is created and first readied into the |
129 | states. When the thread is created and first inserted into the |
129 | scheduler's run queues or when a thread is migrated to a new processor, |
130 | scheduler's run queues or when a thread is migrated to a new processor, |
130 | it is put into the <constant>Entering</constant> state. After some time, |
131 | it is put into the <constant>Entering</constant> state. After some time |
131 | the scheduler picks up the thread and starts executing it. A thread |
132 | elapses, the scheduler picks up the thread and starts executing it. A |
132 | being currently executed on a processor is in the |
133 | thread being currently executed on a processor is in the |
133 | <constant>Running</constant> state. From there, the thread has three |
134 | <constant>Running</constant> state. From there, the thread has three |
134 | possibilities. It either runs until it is preemtped, in which case the |
135 | possibilities. It either runs until it is preemtped, in which case the |
135 | state changes to <constant>Ready</constant>, goes to the |
136 | state changes to <constant>Ready</constant>, goes to the |
136 | <constant>Sleeping</constant> state by going to sleep or enters the |
137 | <constant>Sleeping</constant> state by going to sleep or enters the |
137 | <constant>Exiting</constant> state when it reaches termination. When the |
138 | <constant>Exiting</constant> state when it reaches termination. When the |
Line 218... | Line 219... | ||
218 | essential. If the processor kept running using the stack of the |
219 | essential. If the processor kept running using the stack of the |
219 | preempted thread it could damage it because the old thread can be |
220 | preempted thread it could damage it because the old thread can be |
220 | migrated to another processor and scheduled there. In the worst case |
221 | migrated to another processor and scheduled there. In the worst case |
221 | scenario, two execution flows would be using the same stack.</para> |
222 | scenario, two execution flows would be using the same stack.</para> |
222 | 223 | ||
223 | <para>The scheduling policy is implemented in function |
224 | <para>The scheduling policy is implemented in the function |
224 | <code>find_best_thread</code>. This function walks the processor run |
225 | <code>find_best_thread</code>. This function walks the processor run |
225 | queues from lower towards higher indices and looks for a thread. If the |
226 | queues from lower towards higher indices and looks for a thread. If the |
226 | visited run queue is empty, it simply searches the next run queue. If it |
227 | visited run queue is empty, it simply searches the next run queue. If it |
227 | is known in advance that there are no ready threads waiting for |
228 | is known in advance that there are no ready threads waiting for |
228 | execution, <code>find_best_thread()</code> interruptibly halts the |
229 | execution, <code>find_best_thread()</code> interruptibly halts the |