Midterm review session
CS 202
1 March 2015

---------------------------------------------------------------------------

Ground rules

--75 minute exam

    --at 65 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 78 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, where:
	x <= 65 OR
	65 <= x < 78


--bring ONE two-sided sheet of notes; formatting requirements listed on
Web page

Material

--Readings (see course Web page, the column called "Reading assignment")

--Labs

--Homeworks

--NOT review sessions if the topic wasn't covered in other material (but
the review sessions are specifically designed not to have such things)

NOTE: NOTE: NOTE: Chapter 33 will NOT be covered (it was assigned by
mistake, and will be assigned for real later).

--Lectures

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

--Now questions from you all......