CS 452/652 Winter 2023 - Lecture 10

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 even more complex solution!

Objectives

• correctness → here: deadlock avoidance
• maintenance: multiple developers over time
• performance/control → maximize concurrency
• timeliness → here: watch your idle time
• ⇒ use simplest possible patterns!

Patterns

• scope of patterns
  • control flow
  • concurrency
  • communication
  • synchronization
• patterns must be restrictive to be useful
  • simplicity can only be attained by excluding functionality

Task Types

• client - application logic; typically blocks on send
• server - backend logic; typically blocks on receive
• 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 design/interface
  • verifying coding/internals
• basic technique: inspect and compare → alert
• debugging strategy
  • rule out or confirm problems
  • start with most likely problem?
  • or start with most easy to rule out?

Experiments

• 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...
• execution trace: str pc, <location>