CS 452/652 Winter 2024 - Lecture 6

Scheduling, Optimization, Message Passing

Jan 25, 2024 prev next

Scheduling

• preemption: each kernel entry triggers re-scheduling
  but: no time slicing
• 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

Compiler Optimization

• goal is complete understanding of what we are doing → enable optimization!
  • loop unrolling
  • code without side effects might be removed
  • register caching; repeated reads or writes might be removed
  • code reordering based on performance of microarchitecture
  • compiler understands data dependencies in sequential control flow
• C/C++ keyword "volatile"
  • tells compiler about unspecified side effects related to a variable or memory location
  • compiler avoids reordering around and removal of volatile accesses
  • example: memory-mapped device register

    int cloaddr = 0xFE000000 + 0x3000 + 0x04;
    volatile unsigned int* cloptr = (volatile unsigned int*)(cloaddr);
    unsigned int tval = *cloptr;
    

Runtime/Hardware Optimization

• pipelining and out-of-order execution
• very important challenge in other areas!
• not too relevant for CS 452/652
  • using only one processor core
  • exception handling: hardware cleans up pipeline

Memory & Synchronization

• no shared memory → no memory synchronization
  • no sharing between kernel and user tasks
  • no sharing between user tasks
• no shared data structures → no synchronization (lock, semaphore, etc.)
• 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 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 - do not block!
  • 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()

SRR for Producer/Consumer

• communication pattern; asynchronous buffering; control blocking
• single producer, single consumer (SPSC)
  • producer sends, consumer responds with ack: "push" communication
  • consumer sends/requests, producer responds with element: "pull" communication
• multiple producers, single consumer (MPSC)
  • push communication works → consumer is server
  • pull communication: slow producer might block consumer (and thus other producers)
    • head-of-line blocking
• single producer, multiple consumers (SPMC)
  • push communication: head-of-line blocking
  • pull communication works → producer is server
• multiple producers, multiple consumers (MPMC)
  • need intermediary: buffer ("distributor", "warehouse")
  • buffer: acts as single consumer to producers, single producer to consumers
  • buffer receives requests, processes request, (delayed?) response
  • buffer full or empty: block respective producer(s)/consumer(s)?