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/trunk/src/ch_time.xml @ 57

  → /design/trunk/src/ch_time.xml @ 58

  ↔ Reverse comparison

• Compare Path:	Rev

  With Path:	Rev

Ignore whitespace Rev 57 → Rev 58

/design/trunk/src/ch_time.xml
45,18 → 45,18
<para>The rest of this section will, for the sake of clarity, focus on the
two-register scheme. The decrementer scheme is very similar.</para>
<para>The kernel must reinitialize the counter registers after each clock
interrupt in order to schedule next interrupt. However this step is 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>
<para>The kernel must reinitialize one of the two registers after each
clock interrupt in order to schedule next interrupt. However this step is
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>
<para>Let us assume that the kernel wants each clock interrupt be
generated every <constant>TICKCONST</constant> ticks. This value