60,11 → 60,13 |
<para>Although the kernel does not do any floating point |
arithmetics<footnote> |
<para>Some architectures (e.g. ia64) inevitably use a fixed set of |
floating point registers to carry out its normal operations.</para> |
floating point registers to carry out their normal operations.</para> |
</footnote>, it must protect FPU context of userspace threads against |
destruction by other threads. Moreover, only a fraction of userspace |
programs use the floating point unit. HelenOS contains a generic framework |
for switching FPU context only when the switch is forced.</para> |
for switching FPU context only when the switch is forced (i.e. a thread |
uses a floating point instruction and its FPU context is not loaded in the |
processor).</para> |
|
<para>The last member of the context family is the memory management |
context. It includes memory management registers that identify address |
119,7 → 121,19 |
preemption and thread migration during times when preemption is |
possible.</para> |
|
<figure> |
<formalpara> |
<title>Thread states</title> |
|
<para>In each moment, a thread exists in one of five possible thread |
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 <code>Entering</code> 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 <code>Running</code> state. |
From there, the thread has three possibilities. It either runs until it |
is preemtped, in which case the state changes to <code>Ready</code>, |
goes to the <code>Sleeping</code> state by going to sleep or enters the |
<code>Exiting</code> state when it reaches termination.<figure> |
<title>Transitions among thread states.</title> |
|
<mediaobject id="thread_states" xreflabel=""> |
128,23 → 142,26 |
</imageobject> |
|
<imageobject role="fop"> |
<imagedata fileref="images.vector/thread_states.svg" format="SVG" /> |
<imagedata fileref="images.vector/thread_states.svg" |
format="SVG" /> |
</imageobject> |
</mediaobject> |
</figure> |
</figure></para> |
</formalpara> |
|
<para>HelenOS userspace layer knows even smaller units of execution. Each |
userspace thread can make use of an arbitrary number of pseudo threads. |
These pseudo threads have their own synchronous register context, |
userspace code and stack. They live their own life within the userspace |
thread and the scheduler does not have any idea about them because they |
are completely implemented by the userspace library. This implies several |
things:</para> |
<formalpara> |
<title>Pseudo threads</title> |
|
<itemizedlist> |
<para>HelenOS userspace layer knows even smaller units of execution. |
Each userspace thread can make use of an arbitrary number of pseudo |
threads. These pseudo threads have their own synchronous register |
context, userspace code and stack. They live their own life within the |
userspace thread and the scheduler does not have any idea about them |
because they are completely implemented by the userspace library. This |
implies several things:<itemizedlist> |
<listitem> |
<para>pseudothreads schedule themselves cooperatively within the time |
slice given to their userspace thread,</para> |
<para>pseudothreads schedule themselves cooperatively within the |
time slice given to their userspace thread,</para> |
</listitem> |
|
<listitem> |
153,10 → 170,11 |
</listitem> |
|
<listitem> |
<para>all pseudothreads of one userspace thread block when one of them |
goes to sleep.</para> |
<para>all pseudothreads of one userspace thread block when one of |
them goes to sleep.</para> |
</listitem> |
</itemizedlist> |
</itemizedlist></para> |
</formalpara> |
</section> |
|
<section> |