/design/trunk/src/ch_synchronization.xml |
---|
20,6 → 20,12 |
<title>Active kernel primitives</title> |
<section> |
<indexterm> |
<primary>synchronization</primary> |
<secondary>- spinlock</secondary> |
</indexterm> |
<title>Spinlocks</title> |
<para>The basic mutual exclusion primitive is the spinlock. The spinlock |
99,6 → 105,12 |
<title>Passive kernel synchronization</title> |
<section> |
<indexterm> |
<primary>synchronization</primary> |
<secondary>- wait queues</secondary> |
</indexterm> |
<title>Wait queues</title> |
<para>A wait queue is the basic passive synchronization primitive on |
165,6 → 177,12 |
</section> |
<section> |
<indexterm> |
<primary>synchronization</primary> |
<secondary>- semaphores</secondary> |
</indexterm> |
<title>Semaphores</title> |
<para>The interesting point about wait queues is that the number of |
191,6 → 209,12 |
<section> |
<title>Mutexes</title> |
<indexterm> |
<primary>synchronization</primary> |
<secondary>- mutex</secondary> |
</indexterm> |
<para>Mutexes are sometimes referred to as binary sempahores. That means |
that mutexes are like semaphores that allow only one thread in its |
critical section. Indeed, mutexes in HelenOS are implemented exactly in |
206,6 → 230,12 |
<section> |
<title>Reader/writer locks</title> |
<indexterm> |
<primary>synchronization</primary> |
<secondary>- read/write lock</secondary> |
</indexterm> |
<para>Reader/writer locks, or rwlocks, are by far the most complicated |
synchronization primitive within the kernel. The goal of these locks is |
to improve concurrency of applications, in which threads need to |
287,6 → 317,12 |
<section> |
<title>Condition variables</title> |
<indexterm> |
<primary>synchronization</primary> |
<secondary>- condition variable</secondary> |
</indexterm> |
<para>Condition variables can be used for waiting until a condition |
becomes true. In this respect, they are similar to wait queues. But |
contrary to wait queues, condition variables have different semantics |
296,23 → 332,26 |
the condition becoming true does the following:</para> |
<example> |
<title>Use of <code>condvar_wait_timeout</code>.</title> |
<programlisting language="C"><function>mutex_lock</function>(<varname>mtx</varname>); |
<title>Use of <code>condvar_wait_timeout</code>.</title> |
<programlisting language="C"><function>mutex_lock</function>(<varname>mtx</varname>); |
while (!<varname>condition</varname>) |
<function>condvar_wait_timeout</function>(<varname>cv</varname>, <varname>mtx</varname>); |
/* <remark>the condition is true, do something</remark> */ |
<function>mutex_unlock</function>(<varname>mtx</varname>);</programlisting> |
</example> |
</example> |
<para>A thread that causes the condition become true signals this event |
like this:</para> |
<example> |
<title>Use of <code>condvar_signal</code>.</title> |
<programlisting><function>mutex_lock</function>(<varname>mtx</varname>); |
<title>Use of <code>condvar_signal</code>.</title> |
<programlisting><function>mutex_lock</function>(<varname>mtx</varname>); |
<varname>condition</varname> = <constant>true</constant>; |
<function>condvar_signal</function>(<varname>cv</varname>); /* <remark>condvar_broadcast(cv);</remark> */ |
<function>mutex_unlock</function>(<varname>mtx</varname>);</programlisting></example> |
<function>mutex_unlock</function>(<varname>mtx</varname>);</programlisting> |
</example> |
<para>The wait operation, <code>condvar_wait_timeout</code>, always puts |
the calling thread to sleep. The thread then sleeps until another thread |
421,6 → 460,12 |
<section> |
<title>Futexes</title> |
<indexterm> |
<primary>synchronization</primary> |
<secondary>- futex</secondary> |
</indexterm> |
<para></para> |
</section> |
</section> |
/design/trunk/src/ch_arch_overview.xml |
---|
19,7 → 19,8 |
be used even without some traditional subsystems (e.g. block devices, |
filesystems and networking).</para> |
<figure><mediaobject id="arch1" xreflabel=""> |
<figure> |
<mediaobject id="arch1" xreflabel=""> |
<imageobject role="html"> |
<imagedata fileref="images/arch1.png" format="PNG" /> |
</imageobject> |
26,12 → 27,13 |
<imageobject role="fop"> |
<imagedata fileref="images.vector/arch1.svg" format="SVG" /> |
</imageobject> |
</imageobject> |
</mediaobject> |
<title>HelenOS architecture overview.</title> |
</figure> |
</figure> |
<para>HelenOS is comprised of the kernel and userspace server tasks. The |
<para>HelenOS is comprised of the kernel and the userspace server tasks. The |
kernel provides scheduling, memory management and IPC. It also contains |
essential device drivers that control the system clock and other devices |
necessary to guarantee a safe environment. Userspace communicates with the |
44,6 → 46,10 |
<section> |
<title>Scheduling</title> |
<indexterm> |
<primary>thread</primary> |
</indexterm> |
<para>Kernel's unit of execution flow is a thread. A thread is an entity |
that executes code and has a stack that takes up some space in memory. The |
relation between kernel and userspace threads is 1:1:n, meaning that there |
50,9 → 56,11 |
can be several pseudo threads running within one userspace thread that |
maps to one kernel thread. Threads are grouped into tasks by functionality |
they provide (i.e. several threads implement functionality of one task). |
Tasks serve as containers of threads, they provide linkage to address |
space and are communication endpoints for IPC. Finally, tasks can be |
holders of capabilities that entitle them to do certain sensitive |
<indexterm> |
<primary>task</primary> |
</indexterm> Tasks serve as containers of threads, they provide linkage |
to address space and are communication endpoints for IPC. Finally, tasks |
can be holders of capabilities that entitle them to do certain sensitive |
operations (e.g access raw hardware and physical memory).</para> |
<para>The scheduler deploys several run queues on each processor. A thread |
80,6 → 88,10 |
(i.e. 4-level hierarchical page tables and global page hash table), and is |
further extensible to other mechanisms.</para> |
<indexterm> |
<primary>address space</primary> |
</indexterm> |
<para>Userspace tasks depend on support of address spaces provided by the |
kernel. Each address space is a set of mutually dijunctive address space |
areas that group pages of common attributes. An address space area is |
90,6 → 102,10 |
</section> |
<section> |
<indexterm> |
<primary>IPC</primary> |
</indexterm> |
<title>IPC</title> |
<para>Due to the fact that HelenOS is a microkernel, strong emphasis is |
103,6 → 119,24 |
another or by sending (i.e. sharing) address space areas when larger data |
is to be transfered.</para> |
<indexterm> |
<primary>IPC</primary> |
<secondary>- phone</secondary> |
</indexterm> |
<indexterm> |
<primary>IPC</primary> |
<secondary>- answerbox</secondary> |
</indexterm> |
<indexterm> |
<primary>IPC</primary> |
<secondary>- message queue</secondary> |
</indexterm> |
<para>The abstraction uses terms like phones, calls and answerboxes, but |
is pretty similar to well-known abstraction of message queues. A task can |
have multiple simultaneous simplex connections to several other tasks. A |
/design/trunk/src/ch_memory_management.xml |
---|
189,7 → 189,7 |
<indexterm> |
<primary>slab allocator</primary> |
<secondary>slab cache</secondary> |
<secondary>- slab cache</secondary> |
</indexterm> |
<para>Slabs of one object type are organized in a structure called slab |
205,7 → 205,7 |
<indexterm> |
<primary>slab allocator</primary> |
<secondary>magazine</secondary> |
<secondary>- magazine</secondary> |
</indexterm> |
<para>Each object begins its life in a slab. When it is allocated from |
216,7 → 216,7 |
private <indexterm> |
<primary>slab allocator</primary> |
<secondary>magazine</secondary> |
<secondary>- magazine</secondary> |
</indexterm>magazine cache, from where it can be precedently allocated |
again. Note that allocations satisfied from a magazine are already |
initialized by the constructor. When both of the processor cached |
364,7 → 364,7 |
<indexterm> |
<primary>address space</primary> |
<secondary>area</secondary> |
<secondary>- area</secondary> |
</indexterm> |
<title>Address space areas</title> |
398,7 → 398,7 |
<indexterm> |
<primary>address space</primary> |
<secondary>ASID</secondary> |
<secondary>- ASID</secondary> |
</indexterm> |
<title>Address Space ID (ASID)</title> |
430,7 → 430,7 |
<indexterm> |
<primary>address space</primary> |
<secondary>ASID stealing</secondary> |
<secondary>- ASID stealing</secondary> |
</indexterm> |
<para> |
489,7 → 489,7 |
<indexterm> |
<primary>page tables</primary> |
<secondary>hierarchical</secondary> |
<secondary>- hierarchical</secondary> |
</indexterm> |
<title>Hierarchical 4-level page tables</title> |
512,7 → 512,7 |
<indexterm> |
<primary>page tables</primary> |
<secondary>hashing</secondary> |
<secondary>- hashing</secondary> |
</indexterm> |
<title>Global hash table</title> |
556,7 → 556,7 |
<indexterm> |
<primary>TLB</primary> |
<secondary>TLB shootdown</secondary> |
<secondary>- TLB shootdown</secondary> |
</indexterm> |
<title>TLB consistency. TLB shootdown algorithm.</title> |