Scheduling lessons and Midterm review
CS 170
29 April 2020

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

Scheduling lessons and conclusions

    --Scheduling comes up all over the place

	--m requests share n resources

	--disk arm: which read/write request to do next?

	--memory: which process to take physical page from?

    --This topic was popular in the days of time sharing, when there was
    a shortage of resources all around, but many scheduling problems
    become not very interesting when you can just buy a faster CPU or a
    faster network.

	--Exception 1: web sites and large-scale networks often cannot
	be made fast enough to handle peak demand (flash crowds,
	attacks) so scheduling becomes important again. For example may
	want to prioritize paying customers, or address
	denial-of-service attacks.

	--Exception 2: some scheduling decisions have non-linear effects
	on overall system behavior, not just different performance for
	different users.

	--Exception 3: real-time systems:
	    soft real time: miss deadline and CD or MPEG decode will skip
	    hard real time: miss deadline and plane will crash

	    Plus, at some level, every system with a human at the other
	    end is a real-time system. If a Web server delays too long,
	    the user gives up. So the ultimate effect of the system may
	    in fact depend on scheduling!
	    
    --In principle, scheduling decisions shouldn't affect program's
    results

	--This is good because it's rare to be able to calculate the
	best schedule

	--So instead, we build the kernel so that it's correct to do a
	context switch and restore at any time, and then *any* schedule
	will get the right answer for the program

	--This is a case of a concept that comes up a fair bit in
	computer systems: the policy/mechanism split. In this case, the
	idea is that the *mechanism* allows the OS to switch any time
	while the *policy* determines when to switch in order to meet
	whatever goals are desired by the scheduling designer

	    [[--In my view, the notion of "policy/mechanism split" is
	    way overused in computer systems, for two reasons:
	    
		--when someone says they separated policy from mechanism
		in some system, usually what's going on is that they
		separated the hard problem from the easy problem and
		solved the easy problem; or

		--it's simply not the case that the two are separate.
		*every* mechanism encodes a range of possible policies,
		and by choice of mechanism you are usually constraining
		what policies are possible. That point is obvious but
		tends to be overlooked when people advertise that
		they've "fully separated policy from mechanism"]]

    --But there are cases when the schedule *can* affect correctness

	--multimedia: delay too long, and the result looks or sounds
	wrong

	--Web server: delay too long, and users give up


    --Three lessons (besides policy/mechanism split):

	(i) Know your goals: write them down!

	(ii) Compare against optimal, even if optimal can't be built. 

	    --It's a useful benchmark. Don't waste your time improving
	    something if it's already at 99% of optimal.

	    --Provides helpful insight. (For example, we know from the
	    fact that STCF is optimal that it's impossible to be optimal
	    and fair, so don't spend time looking for an optimal
	    algorithm that is also fair.)

	(iii) There are actually many different schedulers in the
	system that interact:

	    --mutexes, etc. are implicitly making scheduling decisions

	    --interrupts: likewise (by invoking handlers)

	    --disk: the disk scheduler doesn't know to favor one
	    process's I/O above another

	    --network: same thing: how does the network code know which
	    process's packets to favor? (it doesn't)

	    --example of multiple interacting schedulers:

		you can optimize the CPU's scheduler and still find it
		does nothing (e.g., if you're getting interrupted
		200,000 times per second, only the interrupt handler is
		going to get the CPU, so you need to solve that problem
		before you worry about how the main CPU scheduler
		allocates the CPU to jobs)

	    --Basically, the _existence_ of interrupts is bad for
	    scheduling (also true in life)

Midterm 

    Ground rules

    --90 minute exam

    --Via gradescope

    --Exam released at 3 AM pacific time on Monday 05/04 and available until 3 PM
        pacific time on the same day. Once you start the exam you get 90 minutes to
        complete. You must start your exam before 1:30 PM, that is, anytime between
        3 AM and 1.30 PM. Again, once you start the exam you have to finish it in 90
        minutes, that is, press the submit button within 90 minutes.

    --You will type in your answers in gradescope. That is, no scanning of answer
        sheets.

    --Depending on the start time, you may get a different set of questions. But
    all question-sets are designed to have an equal level of difficulty.

    --If you think that a question is ambiguous, then state your (reasonable)
    assumptions and proceed based on those assumptions.

    --You are supposed to do the exam on your own. If you are caught cheating
    (taking help from any other source, for example, another person, the Internet,
    etc.), the consquences will be bad---may result in you not getting a degree
    from UCSB. Note: You _can_ get your degree revoked even if we not detect a
    cheating indidence immediately.
        
    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)

    --Lectures

        --Operating systems: what are they?

            --goals, purpose

        --privileged vs unprivileged mode

            --user-level / kernel interaction: how does the kernel get
            invoked?

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

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

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