Outline

n What we have covered in this class

Course Review n Some sermons!

n Hoare’s Turing Award lecture:

Arvind Krishnamurthy n “Emperor’s old clothes”
Spring 2001
n Butler Lampson:
n “Hints for System Design”

Course Summary OS as Illusion

n Topics covered: n Physical reality vs. Abstraction
n Threads: state, creation, dispatching
n Synchronization: races, inconsistency, semaphores, monitors
n Scheduling: shortest job first, round robin, etc. n Examples:
n Memory management and address spaces: n Single CPU vs. infinite number of CPUs
n Base and bounds, paging, segmentation, combined, TLBs n Interrupts vs. cooperating sequential threads
n Virtual Memory: demand paging, thrashing n Limited memory vs. unlimited virtual memory
n File systems: disk seeks, file headers, directories n No protection vs. each address space has its own machine
n FFS, LFS n Unreliable, fixed size messages vs. reliable, arbitrary messages, and
n Networks: networking components, protocol layers, RPCs network services
n Did not cover:
n Advanced networking topics: congestion control
n Distributed systems: distributed databases
n Security: authentication, protection, code over network

Tony Hoare’s Turing Lecture The Algol60 Story

n Tony Hoare’s accomplishments:
n Quicksort!
n Study of monitors
n CSP language (communicating sequential processes)
n Axiomatic semantics of programming languages
n Turing Award Lecture:
n Anecdotes on simplicity and system design
n Successes: compiler for Algol on Elliot 503
n Failures: operating system (Mark II for Elliot 503)
n Hoare started as a programmer for Elliot Brothers
n Implemented Shell sort and other fast routines
n Designed a variant of Shell sort
n Started looking at designing a new high level language
n In 1961, attended a course on Algol60 by Naur, Djikstra,
Landin
n Was able to implement his sorting variant using recursion
n Decided to use Algol60 as the high level language for their
machines
n Went about designing a modest subset to implement:
n Security: bounds checking!

n Brevity of object code

n Experiences in language design committee meeting
n Fast procedure calls

n Single pass compiler

1
 Algol60 Implementation Significant failure: Mark II
n Designed and documented in Algol60 n Hoare got promoted, and Elliot started building Mark II
n Assembler
n Then coded in machine language by hand! n Automatic code and data overlays from backing core, tape
n Using explicit stack for recursion n Automatic input/output buffering
n Filing system on tape
n Started with a small subset n New implementation of Algol60, Fortran compiler
n Was able to add more features
n Designed system, deadline in 18 months (march 1965)
n Delivered the compiler in middle of 1963 n Revised to June, later revised by another 3 months
n Very few complaints! Satisfied customers n Started digging into the details:
n Limited resource of memory wasn’t handled either by the

n Awarded with membership in the Algol language working committee assembler or the automatic overlay scheme
n Proposed two changes: relax compulsory declarations, case statement n System was occupying most of the memory resource!

instead of a generalized switch statement based on “goto” n Hardware address prevented adding more memory

Failure (contd.) Sermon 1: Simplicity

n Decided to focus on just the Algol60 compiler n Simplicity is an absolute good, not a tradeoff!
n Revised delivery in 4 months n Forces against it:
n Delivered, but n “Intelligence = complexity”
n Original compiler: compiled 1000 chars/second, new compiler: 2 n Marketing à complexity is good (more features)
chars/second! n Can’t sell it, if you can’t build it!
n Problem: thrashing
n Within a week doubled it, and doubled it in another week
n Simplicity makes:
n Systems easier to build, easier to maintain
n Not improving fast enough, project had to be abandoned
n Systems go faster; hard to make big, complex things go fast
n Recovery: n Systems cheaper: quicker to market
n Hoare realized that he shouldn’t let others do what he didn’t
understand himself! n How to make things simpler?
n Called a meeting to discuss the reasons: n Use creativity to simplify
n Lack of machine time, predictable hardware etc., technical
n Design then code
writing for documentation n Be extremist. Maximize simplicity
n Over-ambition!

Lampson’s Hints Subtle Interactions

n Hints on Computer System Design n The Tenex system had these combination:
n Classified into three primary groups: n Reports a reference to an unassigned virtual page by a trap to the
n Functionality, Speed, Reliability user program
n Functionality: n System call also reports any traps it might experience

n Simplicity: zero sum game; complexity costs something n Arguments to system call are passed by reference

n Design the core to be fast, flexible primitives n CONNECT: system call to obtain access to directory (takes a

n Stable interfaces: password argument as a string)

n Flipside: single most important feature of evolution is death
For (I=0 to length of password)
n Plan to throw one away! if (directoryPasswd[I] != passwordArg[I])
n Don’t hide power: wait three seconds; return badpassword
n Flipside of abstraction

n Separate normal and special cases (example: garbage collection) n This system can be cracked!
n Procedure arguments (protocol); leave it to the client n Have password span page boundary
n Example: Spy system monitor, monitor synchronization n See whether you get a page fault early or late

2
 Abstraction Hides Hints on Speed
n Consider a record with lots of fields n Static vs. dynamic
n Exports a FindIthField function n Caching
n Involves a linear scan n Hints:
n Implement FindNamedField using this function n May be accurate, but can check its accuracy
n One possible implementation: n And can recover from inaccuracy
For I=0 to N n Pay attention to constant factors
if (FindIthField(I).name == inputname)
n Do things in the background
break;
n Throughput-centric vs. latency centric view
n Built a O(N^2) algorithm! n Shed load

Sermon 2: Performance Hints on Reliability

n Options for performance tuning: n End-to-end recovery
n Make every line of code as fast as possible n Recover at intermediate stages only for performance
Better: tune selectively
Transactional techniques
n
n
n Only a few places where performance matters n Logs
n 90-10 rule: 90% of the program time in 10% of the code
n Atomic actions
n Difficult to predict performance problems in advance n Typically expensive, do it end-to-end, selectively
n Tuning takes time and makes system more complicated n Design for reliability from beginning
n Biggest gain is going from non-functional to functional
n Hard to retrofit
n How to tell which part matters?
n Measure existing systems
n Modeling
n Simulation
n Profile/measure a real system (try to get 90% of information with
10% effort)

Sermon 3: Life as a CS Person Alan Turing

n If demonstrating an idea/doing research: n Alan Turing (1912-1954).
n Go to the extreme! n Father of computer science.
n Stay broad:
n Breadth helps depth
n Breakthroughs occur when people cross traditional boundaries:
compilers and architecture, graphics and VLSI, etc.; steal from
other fields!
n Computers are tools: need to understand applications
n Technology is changing fast; exploit new changes/shifts
Alan's report card at 14.
n Classic tale: Steve Wozniak after building the Apple 2 Alan Turing and his
n went to Berkeley to get a Masters elder brother.
n he and Jobs visited Xerox PARC, learned from the good ideas

there, and built a Macintosh

3
 Alan Turing (contd.)
n The English report says: "I can forgive his writing, though it is the
worst I have ever seen, and I try to view tolerantly his unswerving
inexactitude and slipshod, dirty, work, inconsistent though such
inexactitude is in a utilitarian; but I cannot forgive the stupidity of his
attitude towards sane discussion on the New Testament." Bottom of
the class.

n He did better in Latin, only second from bottom: "He ought not to be in
this form of course as far as form subjects go. He is ludicrously
behind".

n The maths and science reports were better but still complained: 'His
work is dirty'. He was nearly stopped from taking the School Certificate
(as became O-levels, later GCSE.)