CS 452/652 Winter 2024 - Lecture 20

Software Design, Priorities

Mar 21, 2024 prev next

Train Control

Though Experiment: Perfect Train Control?

• need exact problem specification, example:
  • given a topology, a set of trains, and a list of destinations for each train
    → determine optimal schedule
  • but: what is optimal?
    • time to last train at last destination?
    • average trip duration?
    • many other criteria possible
  • also: assume error-free operation?
• with exact problem specification
  • formulate and solve optimization problem - computational complexity
  • centralized computation difficult for many real world control problems
  • or: design ad-hoc solution accommodate uncertainty (our approach)
• our goal is not overall perfection (which is not even properly specified), but:
  • build interesting multi-task, real-time application
  • model decentralized aspects of real-world system

Travel Objectives

• travel at constant speed level
  • can recalibrate velocity estimate
  • recommendation: slow down before stopping
• travel at specific velocity
  • timed adjustment of speed level, verify via sensors
• travel in cohort: multiple trains at specific distance
  • adjust one or both trains, verify via sensors

Design Approach

• attribution server
  • all travel plans with expected timing
  • disregard conflicts
  • query interface: <location, time> → train(s)
• reservation server
  • continuous reservations (no leapfrogging)
  • consider directionality of reservation
  • reservation interface: <train, segment, direction> → result
    • result: segment available or direction of reservation
    • timing information?
• collision avoidance server
  • short-term travel plans only
  • no timing information
  • check for conflicts
• routing server
  • determine path & feasibility (e.g. short move?)
  • take into account track exclusions? query interface?
• sensor task
  • receive sensor reports
  • query attribution server
  • send notifications to train tasks
• train task
  • source/dest → obtain route from route server
  • drive train loop
    • reserve track segments
      • reserve beyond branches
      • reservation denied: slow/stop
      • invariant: reservation distance > stop distance
    • switch reserved turnouts
    • core loop
      • update/submit travel plan
      • set train speed
      • handle sensor, timeout notifications
      • any problem? stop/slow, make new plan (timing and/or routing)
    • release track segments
      • periodic or sensor-based updates
      • leave segment → release segment
      • pass turnout → release alternative path
      • stop → release rest of path
• conflict resolution:
  • contention → back off
  • move/avoid conflict zone by changing speeds
  • find alternative paths
  • computational overhead with more trains?

Priorities

How to Set Priorities?

• prioritze application-meaningful operations
  • sensor-command activation cycle
  • sensor polling loop
  • user interface
  • route planning, route setup
• mapping operations to tasks
  • problem: same task doing high- and low-priority operations
    • route planning vs re-routing
    • clock services for low- and high-priority tasks
    • train server handling high (stop) and low (go) priority commands
  • static solution: split tasks, e.g, high- and low-priority train server
    • not always practical: ensure atomicity command at a time to the Marklin
    • servers often have to handle requests from processes with different priorities
  • prioritize messages or operations?

Priority Inversion

• lower-priority tasks indirectly keeps higher-priority task from running
• latency problem: performance and/or correctness
  • unintended starvation, if system fully loaded
• examples: assume lower numbers are higher priorties
• Scenario A
  • Server T₃ running on behalf of T₁, then T₂ preempts
    → T₁ waits for T₂
• Scenario B
  • Server T₃ running on behalf of T₅, then T₄ wants to run
    → T₄ waits for T₅
• Scenario C
  • Server T₃ idle or preempted, T₂ running, then then T₁ sends to T₃
    → T₁ waits for T₂
• dynamic prioritization
  • promote server priority to priority of active request (Scenario A)
  • demote server priority to priority of active request (Scenario B)
  • promote server priority to highest priority queued request (Scenario C)
• kernel can support dynamic prioritization
  • carry sender's priority in internal message
  • also: priority queue of waiting senders?
• further reading: Priority Inheritance Protocols: An Approach to Real-Time Synchronization