HelenOS-docHelenOSHelenOS-historic

Català-Valencià – Catalan中文 – Chinese (Simplified)中文 – Chinese (Traditional)Česky – CzechDansk – DanishNederlands – DutchEnglish – EnglishSuomi – FinnishFrançais – FrenchDeutsch – Germanעברית – Hebrewहिंदी – HindiMagyar – HungarianBahasa Indonesia – IndonesianItaliano – Italian日本語 – Japanese한국어 – KoreanМакедонски – Macedonianमराठी – MarathiNorsk – NorwegianPolski – PolishPortuguês – PortuguesePortuguês – Portuguese (Brazil)Русский – RussianSlovenčina – SlovakSlovenščina – SlovenianEspañol – SpanishSvenska – SwedishTürkçe – TurkishУкраїнська – UkrainianOëzbekcha – Uzbek

Compare Revisions

• This comparison shows the changes necessary to convert path

  → /design/ @ 138

  → /design/ @ 139

  ↔ Reverse comparison

• Compare Path:	Rev

  With Path:	Rev

Ignore whitespace Rev 138 → Rev 139

/design/trunk/src/ch_ds.xml
4,11 → 4,11
<title>Data Structures</title>
<para>There is lots of data that either flows through various HelenOS
<para>There is a lot of data that either flows through various HelenOS
subsystems or is stored directly by them. Each subsystem uses its own data
structures to represent the data. These data structures need to be kept
somewhere. In order to work efficiently, HelenOS, and especially its kernel,
deploys several house keeping data types that are designed to faciliate
deploys several house keeping data types that are designed to facilitate
managing other data structures. Most of them serve like generic
containers.</para>

/design/trunk/src/ch_time.xml
4,11 → 4,11
<title>Time Management</title>
<para>Time is one of the dimensions in which kernel, as well as the whole
system, operates. It is of special importance to many kernel subsytems.
<para>Time is one of the dimensions in which kernel as well as the whole
system operates. It is of special importance to many kernel subsytems.
Knowledge of time makes it possible for the scheduler to preemptively plan
threads for execution. Different parts of the kernel can request execution
of their callback function with some specified delay. A good example of such
of their callback function with a specified delay. A good example of such
kernel code is the synchronization subsystem which uses this functionality
to implement timeouting versions of synchronization primitives.</para>
50,13 → 50,14
tricky and must be done with caution. Imagine that the clock interrupt is
masked either because the kernel is servicing another interrupt or because
the processor locally disabled interrupts for a while. If the clock
interrupt occurs during this period, it will be pending until interrupts
are enabled again. In theory, that could happen arbitrary counter register
ticks later. Which is worse, the ideal time period between two non-delayed
clock interrupts can also elapse arbitrary number of times before the
delayed interrupt gets serviced. The architecture-specific part of the
clock interrupt driver must avoid time drifts caused by this by taking
proactive counter-measures.</para>
interrupt occurs during this period, it will be pending until the
interrupts are enabled again. Theoretically, it could happen an arbitrary
counter register ticks later. Which is worse, the ideal time period
between two non-delayed clock interrupts can also elapse arbitrary number
of times before the delayed interrupt gets serviced. The
architecture-specific part of the clock interrupt driver must avoid time
drifts caused by such behaviour by taking proactive
counter-measures.</para>
<para>Let us assume that the kernel wants each clock interrupt be
generated every <constant>TICKCONST</constant> ticks. This value