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!