CS 452/652 Winter 2026 - Lecture 7

Scheduling and Communication

Jan 27, 2026 prev

Scheduling

• preemption: each kernel entry triggers re-scheduling
  but: no time slicing, no fair scheduling
• after kernel entry and corresponding processing
  • task might be blocked → track
  • task might be ready → back on ready queue
    but not both! single intrusive linkage element sufficient
• ready queue - keep simple: array of plain FIFO queues
  • no support for timeout/cancellation of blocking operations
  • no need to remove internal element from queue
  • only push to back of queue, pop from front

Memory & Synchronization

• no shared memory → no synchronization (lock, semaphore, etc.)
  • no sharing between kernel and user tasks
  • no sharing between user tasks
• task/kernel communication via system calls
• task/task communication by passing messages
• resource synchronization: via task patterns
  • e.g. track server task mediates access to track
• device synchronization: kernel primitive AwaitEvent()

Message Passing

• synchronous communication: Send/Receive/Reply (SRR)
  • data flows when both sender and receiver are ready
  • no asynchronous buffering
• requires blocking (i.e., suspending/resuming) tasks
  • kernel needs to track blocked tasks
  • reply guaranteed without blocking
• sender state: SendWait, ReplyWait
• receiver state: ReceiveWait
• Send/Receive Scenario 1: Send first
  • T1 Send
    • receiver tid: look up receiver - not in ReceiveWait
    • sender blocks (Ready → SendWait)
      • where to store information about senders? at receiver
  • T2 Receive
    • finds sender - sanity check for SendWait
    • sender still blocked (SendWait → ReplyWait)
    • kernel copies data
    • T2 still Ready
• Send/Receive Scenario 2: Receive first
  • T1 Receive
    • no sender found
    • receiver blocks (Ready → ReceiveWait)
    • store receive-blocked tasks in kernel container? only for cleanup/housekeeping
  • T2 Send
    • receiver tid: look up receiver - in ReceiveWait
    • unblock receiver (ReceiveWait → Ready)
    • block sender (Ready → ReplyWait)
    • kernel copies data
• Reply
  • non-blocking: sender must be waiting
  • sender tid: look up sender - sanity check for ReplyWait
  • unblock sender (ReplyWait → Ready)
  • kernel copies data
• Receive from anyone
  • no upfront filtering
  • sender's tid transmitted via Send/Receive
• Receive and Reply can be decoupled
  • in time: sender parked until later reply (reordering)
  • in space: different task replies than original receiver (delegation)
• kernel provides SRR functionality
  • provide mechanisms for blocking senders and/or receivers
  • message copying for safe asynchronous operation of sender & receiver
    • direct copy from sender to receiver and vice versa
    • no message buffering in kernel
    • kernel must also set return codes appropriately
• messages: structured data
  • no conversion (marshalling) needed as in heterogeneous distributed systems
  • copied as byte (char) array
  • type-checking: verify type of message for type of task?
    • want global type field per message?

Server Pattern

• background: reasoning about latency of critical code paths - avoid/control blocking
  • design system to control latencies!
• server provides service to clients
  a) receive request
  b) process
  c) (delayed) response
  → server always available or working: never blocks
  never calls Send() or AwaitEvent()

Programming

• important principle: KISS
  • and: "premature optimization is root of all evil" (Donald Knuth)
• availability of resources: track < ARM < developer < PC
• think strategically about
  • functionality: start simple, add functionality in small steps
    • test (and commit) at each step
  • data structures: encapsulate, start simple, exchange later
  • bugs: not every bug is a show-stopper
• use unit testing where possible
• use assertions generously!
• ultimate goal is understanding everything!