CS 452/652 Spring 2025 - Lecture 10

Software Design, Debugging

June 5, 2025 prev next

Software Design

Basics
- each problem presents a complexity floor
  - how many inputs?
  - timing requirements?
  - computational complexity?
  - load & performance requirements?
- no software design/engineering in the world can produce a simpler solution
  but: it is possible to screw up and build an unnecessarily complex solution!
Objectives
- performance → maximize concurrency
  - control → priority scheduling
  - responsiveness → watch your idle time
- correctness → deadlock avoidance
- simplicity → use simplest possible patterns!
Patterns - semi-automatic reasoning about software
- dimensions:
  - control flow
  - concurrency
  - communication
  - synchronization
- patterns must be restrictive to be useful
  - simplicity can only be attained by excluding functionality
  - "It seems that perfection is attained not when there is nothing more to add, but when there is nothing more to remove."
    Antoine de Saint Exupery
    https://en.wikiquote.org/wiki/Simplicity
Task Types
- server: backend logic; only blocks on receive
- client: application logic; isolating concerns
- worker: simple!

Worker Patterns

notifier - blocks on events (interrupts)

for (;;) {
    AwaitEvent()
    Send()
}

courier - transmits data between servers

for (;;) {
    Send(server1, req, msg); // pull from server1
    Send(server2, msg);      // push to server2
}

Debugging

often ad-hoc activity - reflect on it...
- fundamentally:
  - software: model ↔ implementation
  - debugging: reconcile model and implementation
  - (your) program vs. environment (soft- and hardware)
- what's in a bug?
  - error in model?
  - incorrect implementation?
  Model Implementation
  
  Program Design Coding
  
  Environment Interface Internals
- potential problems
  - design: your model is incorrect
  - coding: your implementation does not realize your model
  - interface: your understanding of the environment is incorrect
  - internals: there is an unknown bug in the environment (unlikely)
- debugging helps with verifying assumptions
- basic technique: inspect and compare → alert
- debugging strategy?
  - confirm or reject assumption
  - start with most (or least) likely assumption?
  - or start with most easy to confirm or reject?
Experiments
- testing & debugging fundamentally uses scientific methodology
  - build model → gather data → compare → repeat
- no amount of experimentation can ever prove a model correct!
Tools
- tracing, logging (print)
- checking (assert)
- snapshot inspection
- interactive debugging: breakpoints, single-stepping (if possible)
  - post-mortem (if reboot keeps RAM): need custom software
- source or binary instrumentation
- stack backtrace? see 'man backtrace' on Linux
  - not available in newlib, you could re-implement...
Timing Challenges
- real-time: timing critical for correctness
  - interactive debugging difficult
- non-determinism: timing influences functionality
  - debugging changes timing behaviour: bug might disappear after changes
- concurrency → non-determinism (race conditions)
  - software and real-world (trains)
Race Condition (origin in circuit electronics)
- (data) race: concurrent/parallel access to same resource
  - potential problem if one access is mutation
    → correctness problem, if one of the possible outcomes are wrong
    → ordering problem, repeatability
- atomicity at bit level?
- atomicity at word level? assignment vs. increment
- race condition: problematic race requires coordination (synchronization)
  - coordination → performance vs. control
    - example: spin lock vs. mutex lock vs. fifo
    - lock-free coordination: typically spinning
  - non-determinism: matter of magnification/zoom/details?
    - actual sources of non-determinism: timer, keyboard, train
  - exact tracing in concurrent software too onerous
- therefore we might see
  - high-level races: concurrent requests to resources (train, track)
  - non-repeatability: add/remove print statements?
  - asynchronous interrupts - should be no problem...

	Model	Implementation
Program	Design	Coding
Environment	Interface	Internals