Final review session CS 202 12 May 2015 Ground rules --110 minute exam --at 100 minutes, you have to stay seated; do not get up and distract your classmates. --you must hand your exam to me (we are not going to collect them). the purpose of this is to give everyone the same amount of time. --at 115 minutes, I will walk out of the room and won't accept any exams when I leave --thus you must hand in your exam at time x minutes, x <= 100 or 110 <= x < 115 --you can bring TWO two-sided sheet of notes; formatting requirements listed on Web page --**NOTE**: We do not guarantee that these review notes are necessary or sufficient: there is likely to be material on the final that is not referenced here, and there is likely to be material referenced here that is not on the final. Material --Readings --Labs --Homeworks --Lectures. Following topic list taken nearly verbatim from first two midterm reviews --Operating systems: what are they? --goals, purpose --privileged vs unprivileged mode --Processes: birth, life cycle, state diagram, implementation --what are they? (registers, address space, etc.) --birth: fork()/exec() --context switches (when? how?) --view of memory (call stack, heap, program code, etc.) --Privileged vs. unprivileged mode --user-level / kernel interaction: how does the kernel get invoked? --How the OS gets booted --system calls --shell --the fork()/exec() separation --the power of Unix's abstractions --threads --concurrency --hard to deal with; abstractions help us, but not completely --critical sections --mutexes --spinlocks --condition variables --monitors --lots of things can go wrong: safety problems, liveness problems, etc. --> lack of sequential consistency makes the problem worse. --What's the plan for dealing with these problems? --safety problems: build concurrency primitives that get help from hardware (atomic instructions, turning off interrupts, etc.) and move up to higher level abstractions that are easy to program with --liveness problems: most common is deadlock, and we discussed strategies for avoiding it. other problems too: starvation, priority inversion, etc. --lots of trade-offs and design decisions --performance v. complexity --lots of "advice". some is literally advice; some is actually required practice in this class. --software safety (Therac-25) --scheduling --intro: when scheduling happens, which metrics, what costs --specific disciplines --lessons and conclusions --I/O --architecture --how CPUs and devices interact --mechanics (explicit I/O instructions, mem-mapped I/O, interrupts, memory) --polling vs. interrupts --DMA vs. programmed I/O --device drivers async vs sync I/O (non-blocking vs blocking I/O) virtual memory segmentation paging segmentation vs paging virtual memory on the x86 virtual address: [10bits 10bits 12bits] --entry in pgdir and page table: [20 bits more bits bottom 3 bits] --protection (user/kernel | read/write | present/not) what's a TLB? page faults mechanics costs uses page replacement policies (FIFO, LRU, CLOCK, OPT) thrashing [latter two topics more general than paging: applies to caching in general] alternatives to preemptively scheduled shared memory threads cooperatively scheduled threads, implemented in user space event-driven programming disks geometry performance interface scheduling (skipped in lecture; see book) technology trends file systems --basic objects: files, directories, meta-data, links, inodes --how does naming work? what allows system to map /usr/homes/bob/index.html to a file object? --types of file layout --extents/contiguous, linked, FAT, indexed structure --classic Unix and FFS are variants of indexed structure --analogy between inode and page directory --tradeoffs --performance AFTER MIDTERM 2 crash recovery --ad-hoc: write meta-data synchronously and in the right order --depend on fsck --ordered updates: write meta-data in the right order but not necessarily synchronously --depend on fsck --write-ahead logging (called *journaling* in FS context) transactions --notions of atomicity: --with respect to crashes --with respect to concurrent transactions --we used a bunch of mechanisms, including but not limited to: --transactions API (begin_trans(), end_trans(), commit(), abort()) --undo/redo log + recovery protocol (can usually get away with redo logging, only) --locking --concept of a commit point RPC, client/server systems case study: NFS (network file system) --marquee user of RPC --RPC: transparent or not? distributed systems --what makes them hard? --two generals' problem --distributed transactions, two-phase commit protection and security --stack smashing / buffer overflow --Unix security model --access control, privileges (explicit and implicit), setuid, attacks --security thoughts generally: when do you use which tool? --trusting trust