Lecture #1

Administrivia

• Anybody here for computational geometry?

  • just kidding--my sense of humor
  • if you've already looked at assigment 1, don't panic (yet)

• CSS 503A--Systems Programming

  • AKA Operating Systems
  • key questions:
  • What's an operating system?
    • how are they put together?
    • how do they work?
  • How to interface with Operating Systems services?
    • how to work with them?

• Turnkey course: largely following Professor Fukuda's notes

  • plus my own spin, of course--value added

• Fast-paced: will be firing a lot of new concepts fired at you

  • repetition: it will sink in
  • bear with me
  • don't panic

• Classes:

  • M-W 6-7:45pm
  • UW1-041

• Office hours:

  • after class & Sunday afternoons from about 1:30pm
  • Linux lab: UW1-320
  • can arrange to meet elsewhere on campus for privacy if requested
  • my general policy is that I will talk to almost anyone about almost anything during office hours
  • office hours are generous--use them

• Grading:

  • 50% assignments
    • 4 assignments
    • 4^th is worth 20%
  • 50% exams
    • midterm (25%)
    • final (25%)
  • Final grades will be adjusted

Ground Rules for Assignments (Fit & Finish)

• README file

• BUILD and, if nontrivial, RUN scripts

• Source code

• Sample data & expected output

  • NO large data files!

• other stuff as required: reports, diagrams, graphs

• NO screen shots

  • I can't grep screen shots

• Unless otherwise indicated:

  • input from standard input (cin)
  • output to standard output (cout)
  • meta-info, error messages, debug/logs, etc. to standard error (cerr)

• use .cc or .cpp file extension for source files

  • I prefer .cc, but your choice for your source

• Instructor's C++ pet peeves

  • do not #include .cc/.cpp files
    • use .h, for #include files, or if you must include template implementations separately, -impl.h or .inc
  • do not remove copyright notices from skeleton code; you may augment with your modifications, but do not claim someone else's work as your own

Your instructor generally hates arbitrary and petty things, but these points matter in your instructor's humble opinion.

README file

• Any specifically requested results (e.g. performance measurements)

• Brief thoughts about the assignment

  • discussion of program design, results, lessons learned, possible improvements, ...

• Anything else you want to tell me

• May be a paragraph or two

  • don't spend too much time on it

Build & Run Scripts

• Fit and finish: your assignment is incomplete if I don't know how to build or run it, or if I have to type a long command line (with lots of flags) to compile your program.

• May simply encapsulate the same g++ command you type at the prompt, or be more elaborate (call make, check for success, run unit tests, ...)

  • will not be graded, but expect to lose marks if not present

• Does not have to be your own work if used with permission and properly cited

  • citation matters: never claim someone else's work as your own

C++ Coding

• Compile with -Wall (maximum warnings), -Werror (warnings treated as errors), and -pedantic (strict ISO compliance) flags

• Check return codes from system calls

  • usually OK for the purposes of assigments to terminate on errors (fix the problem and re-run the test), but do detect the problem
  • a program crash is better than undetected bad output

• Good resource management

  • don't waste resources unnecessarily
  • ephemeral programs: don't bother collecting garbage; program termination does that for you!

• Readable style

  • don't make my eyes bleed
  • be consistent with naming and indentation
  • for specific guidance see any of several published style guides
    • https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md
    • http://www.stroustrup.com/Programming/PPP-style-rev3.pdf
    • https://google.github.io/styleguide/cppguide.html (a bit dated, but I still like a lot of what it says, particularly that it discusses pros, cons, and decision)

Linux

Most of you are new to Linux. Not going to waste valuable class time going over basic user-level stuff. You are expected to develop your working knowledge on your own time.

• impromptu tutorials during office hours on request

• plenty of resources available on the interwebs

Academic Conduct

• You guys have been around, so I shouldn't have to read you the riot act on cheating.

  • I take cheating as a personal insult
  • I am required to report occurrences to the university and I hate doing that kind of paperwork

• Office hours are generous and I want you to succeed

  • unless you cheat or are not really trying

• You are learning skills vital to your future career (whether in academia or industry). If you cheat, you are cheating yourself

• Don't panic! I am here to help you.

Digression: About Engineering & Software Engineering

(I try to say something about this in every class I teach)

• Engineering (in general) in a single word: tradeoffs

  • time/space (algorithms)
  • complexity/performance
  • cost/schedule/features/quality
  • delivery time vs. maintainability

  (TODO: insert triangle diagram)

• Double win: sometimes you get a solution that is "better" without sacrificing other aspect(s)

  • e.g. numpy (compiled library embedded in interpreted language)
  • but that's relatively rare; mostly you're navigating around antagonistic constraints

• Double jeopardy: sometimes there are constraints you cannot trade off

  • 9 women cannot have a baby in a month

• Software engineering in a word: abstraction

  • key concept, many aliases
    • modeling
    • information hiding
    • public/private parts
    • APIs
    • microservices
    • abstract data types
    • container classes
    • decomposition
    • interface/implementation
    • modules
    • namespaces
    • objects/classes
    • magic
  • discard/hide nonessential details: depends on the application
    • airplane for air traffic control system: position, altitude, heading, airspeed
    • airplane for airline reservation system: collection of seats
    • airplane for mainenence support system: collection of parts and/or required inspections

• Why? Because we don't have the mental capacity to build & maintain large-scale (software) systems

• Solution: build system in layers af abstraction

  • don't worry about "details" handled by "lower" layers
  • lower layers are magic
  • same person may be responsible for multiple layers, but does not have to think about more than one layer at a time
    • easier to switch hats/gears between the layers than to try maintaining everything in your head simultaneously

• Cost (tradeoff) of abstractions: less-efficient use of machine resources

  • not always: e.g. Numpy in Python (implemented in C & Fortran, linked into Python interpreter)
  • but usually

• Abstractions may result in net increase in complexity, but partition the complexity so you don't have to deal with it all at once

  • simple systems may become over-complicated/over-engineered from excess abstraction
    • see: FizzBuzz Enterprise Edition) (https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition)

• Most of the time, we live in a world where programmer time is more valuable than machine resources

  • consider: 10 minutes to code & 10 minutes to run vs 1 hour to code & 3 seconds to run (just grab a coffee while you're waiting)

• Often enough, it does matter

  • consider: deployment on 10K servers (@ $5k/server: 50 million dollars) vs 50 servers (1/4 million dollars)
  • 200x performance differences is not uncommon

• Example of dramatic difference: sum two matrices in different languages by row and column

  Language	Sum by Rows (ms)	Sum by Columns (ms)
  C++	0.4	10.8 (2.5x)
  Java 1	4 (10x)	154 (385x)
  Java 2	3.6	138
  Python 1	170.9	237.1 (~600x)
  Python 2	258	332 (> 800x)

TODO: insert code

• In this class, we're going to explore a world where performance (usually) matters

  • why does performance matter?
    • OS is base layer upon which everything else depends

• Why study this?

  1. to understand (on a visceral level) that lower levels are not (really) magic
  2. to be able to use machine resources efficiently when it matters

• interestingly, performance seems to matter most on the largest (datacenter-scale) and smallest (embedded/real-time) machines

Operating Systems -- Intro

• What's an operating system?

  • don't know: multiple definitions, depends on point-of-view

• history: how we got to where we are today

• system architecture

  • protection (one process can't scribble over another)
  • resource management
    • I/O
    • asynchronous operation
    • memory management
      • each process gets logical/virtual address space
      • disk management
        • logical view: directories & files

History

• Earliest days of computing (before my time): batch systems

  • programs & data encoded on 80-column punch cards
  • output to "line printer"
    • z-fold paper with sprockets
  • maybe, if you're lucky, you get a tape drive
    • movies from that era always show the tape drives & blinking lights

• Personal anecdote (~ early 2000s): Uncle Zavie cleaning up personal papers, found a flowchart he did for a program on a 1960s-era computer (beautiful calligraphy!)

  • main memory on rotating drum (like disk but data is on surface of a cylinder)
  • assembly-language instructions include address of next instruction
  • attempt to figure out location of next instruction such that next instruction will come under read head just as the computer is ready to read next instruction
  • worst-case latency: full revolution of drum

• Batch systems

  • you "own" entire computer
  • do one thing at a time (single thread of execution)
  • "reboot" between jobs
  • each program has to include all code including I/O operations

• Functions common to all programs stored in "libraries" (think physical file cabinets containg programs on punch cards)

  • "ordinary" code, collected & reused

• I/O operations are much slower than CPU operations --> inefficient use of expensive (dollarwise) resources

  • a single computer is a room full of equipment, puny by today's supercomputer-in-a-pocket standards

• Solution: run several jobs/tasks processes concurrently

  • but a computer can only do one thing at a time
  • even if you could do things concurrently, two programs might need simultaneous access to common resources
    • e.g. two programs writing concurrently to log file or console: output gets interleaved

• Coming soon: architecture that makes concurrent computing possible

• Fast-forward to present time: these problems are basically solved

  • modulo ongoing improvements, more ambitious system architectures, etc.

Key OS Concepts

1. Device management (device drivers)
   • efficient use of hardware resources
   • provide access to devices via well-defined interfaces
     • user-level access to hardware via operating-system calls (system requests)
2. Process management
   • create, schedule, teardown
   • inter-process communication
   • manage concurrency
     • yield processor when performing long-running I/O operations
     • fair scheduling (what is fair? TBD)
   • manage contention for system resources
3. Filesystems
4. Networking
   • complex (low-level) protocols: TCP/IP & UDP/IP
5. Security/safety
6. Convenience: API for userland (application) programs

Working Definition

1. Traffic cop
2. Resource allocator (CPU, memory, disk, ...)
3. Control program (Tron: "Master Control Program")

4. Hardware Abstraction Layer ("virtual" machine)

   • not "virtual machine" in modern sense -- that's another story

5. Goal:

   • make it easier to use the computer
   • make efficient use of hardware resources

6. processes

   • memory management
7. filesystems

OS: Kernel vs. Full Distro

• Linux: kernel (core of operating system)

• Linux Distro (Distribution) aka GNU/Linux:

  • kernel
  • 1000s system/user application programs
  • installation program (e.g. Anaconda)

• Shell (Bash): not operating system

  • ordinary userland application
  • can choose from several (sh, csh, tcsh, ksh, bash, ...)
  • or roll your own
  • other programs may include shell-like functionality

• Similarly for Windows

  • OS + utilities + applications
  • "browser" is essential part of operating system (?)

Layered Model

• TODO: layered diagram

• "system services" (e.g. print server) reside in userland

• applications

  • CLI (command-line interpreter), i.e. shell
  • GUI (graphic user interface)
  • IDE (integrated development environment)
  • compiler/assembler/linker
  • language interprater, e.g. Python, Perl, Node (JavaScript)
  • JVM
  • text editor, e.g vi, emacs
  • spreadsheet, e.g. Excel
  • word processor, e.g. Word
  • browser, e.g. Chrome, Safari, Edge
  • games, e.g. minesweeper, solitaire
  • ...