 |
|
|
Spring 2004
Introduction: Speedy, reliable, flexible software systems must be easy to program, so that programmers can analyze and improve the systems' performance and correctness. This seminar will look at recent systems literature, focusing on tractability, programmability, and ease of analysis: in a word, readability. What does "software system" mean here? A program that interacts with the outside world (other programs) under unusual performance and/or reliability constraints. Canonical examples are operating systems, routers, load balancers, web servers, and databases. Microsoft Flight Simulator isn't a software system by this definition: who cares if it fails? But programs that run on actual airplanes are. What does "readable" mean? Programmable, extensible, easy to reason about, and fun. Probably "programmable" and "fun" are most important. My underlying assumption is that systems programming is not fun enough (although it's pretty fun). Systems would be better if systems programming were more fun, because then we'd want to solve system problems, rather than to avoid dealing with them. We'll focus less on automatic techniques, and more on human programmers. Over the course of the term, we should cover individual system abstractions, performance measurement and analysis, building blocks like scheduling and notification, state storage (soft state vs. hard), distributed system structure (peer-to-peer vs. client/server), security, and more. This course differs from Rupak's Computer-Aided Verification seminar and Todd's seminar in a couple ways, but it will be useful to take all three. In this seminar, systems issues like performance will be primary, and our goal is to broadly improve readability; we'll cover individual techniques like verification in less depth. Fewer proofs, more code. The class will be structured around presentations of papers from the recent systems literature, and a project. (There may also be programming assignments.) One type of good project would be to take a software system important for your research and use techniques learned throughout the term to make it more "readable". The project writeup would contain both code comparisons and in-depth measurements, showing how the system improved its performance and/or reliability. Tentative Grading: 25% paper presentations and discussion, 75% assignments and projects. There will be no midterm or final exam. Informal Prerequisites: CS 111 (Operating Systems) or equivalent. Systems programming experience will be extremely helpful.
|
|||||||||||||||||||||||||||||||||||||||