CS 452/652 Winter 2022 - Lecture 13

Clock Server

• main loop of receiving and processing requests
• server never blocks ⇒ cannot call AwaitEvent()
• task blocking delegated to clock notifier
• server & notifier → general design pattern

Server Processing

• TIME: reply to client with current clock value
• DELAY: park client task (using tick & tid) in timer list
  • two variations: absolute vs. relative tick
• TICK: advance clock value and check parked tasks in timer list
  • reply to clients whose waiting times have completed
• timer list should probably be a sorted data structure

Clock Notifier

• main loop (at high priority)

  loop:
    AwaitEvent()
    Send() tick to clock server
  

Idle/Halt

• what to do when processor has not other work?
  • SETI? cryptomining? → often not appropriate!
  • maintenance, e.g., garbage collection → not relevant for CS 452 kernel
  • diagnosis, such as computation of idle fraction
  • save energy → halt! (cf. "race-to-idle/sleep")
• implement as dedicated idle task at lowest priority

  for (;;) {
    while (maintenance()) yield();
    park();
  }
  

• ARMv4T has no dedicated instruction for 'park'
• EP 9302 provides device register to gate CPU clock (Section 5.2 in EP93xx User Guide)
  • read from 0x80930008 triggers halt
  • next IRQ wakes up CPU again
• alternative: write to co-processor register (Section B6.6.5 in ARM Architecure Reference Manual)
  • only works in privileged mode...

Race

• concurrent or parallel access to shared resource - at least one write
• results in non-deterministic outcome
• coordination to avoid races has overhead
• not all races are problematic! but:
  • correctness problem, if at least of the possible outcomes is incorrect
  • repeatability problem, especially with program modifications (debugging)
• data races very prevalent for multi-cpu computing
  • careful approach to coordination needed to attain highest performance
• non-determinism in CS 452
  • track and trains → sensor reports
  • human operator
• races in CS 452
  • could arise during interrupt handler when accessing shared data
  • however
    • kernel (and interrupt handler) is not interrupted
    • only user tasks are interrupted
    • user tasks do not share data with each other
  • but be aware of the potential problem!