CS 452/652 Winter 2024 - Lecture 10

Software Design, Debugging

Feb 8, 2024 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
    • timeliness → 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; isolation
  • 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...
  • execution trace: str pc, <location>, then post-mortem

• 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...