amy hwang lecture notes 1/29/2007 --------------------------------- SCHEDULING fair share scheduling algorithm - CPU usage fairly distributed among system users instead of equally distributed - keep history of recent CPU usage per process, highest priority given to least CPU time recently - so highly user-interactive processes get priority over CPU-intensive jobs, result is users will see rapid response in UI - e.g. priority = wait_time - 10*cpu_use - MLFB or exponential queue systems can use this kind of job ordering bsd unix scheduling - note recommended text on berkeley unix - multilevel feedback queues (128 priority levels into groups of 4 => really only 32 levels) - jobs run in time slices, and are requeued at the end of quantums - system jobs have highest priority in queue - quantum = 0.1 seconds in 4.3BSD (longer quantums give "jerky response") - quantums cannot be preempted - priority levels 0-49 reserved for system processes. 50-127 for user processes. - user priority = priority(user) + priority(cpu) + priority(nice) - p(user) => highest goes to OS processes - p(cpu) => increases as this process uses CPU time - p(nice) => number that allows you to decrease priority (don't interfere with high priority jobs) DEC - DEC is really just a version of berkeley unix - before it was gobbled up by Compaq, DEC was very prominent in the computer business (sold fairly expensive machines) - then came out with workstations costing only $3000-$5000, but almost as fast as big machines - question: why not just use these workstations for timesharing instead of big machines? - evidence: when more than 2 people log onto this workstation at the same time, it gets really slow - hypothesis: DEC intentionally uses very large quantum for workstations to make them unusable for timesharing scheduling countermeasures - break up large computations into many smaller ones - not acceptable: get bumped up to higher priority by doing fake IO (to /dev/null) scheduling summary - should only affect performance (flow, throughput, overhead), and not the correctness out the final output - in general, best schemes are adaptive and preemptive - purpose of hw1 is to simulate these schemes and draw some conclusions about them - counterintuitive conclusion: best scheduling algorithms give highest priority to the processes that need the least --------------------------------- INDEPENDENT AND COOPERATING PROCESSES independent processes - can't affect or be affected by rest of universe (rare) - no shared state with other processes - deterministic and reproducible - independent of when you run it (only time varies) processes are not independent when... - they share a file with another process - they use input/output - there are conflicting resources - they are part of same command cooperating processes - share some state, even if they are not cooperating - we're interested in reproducible results, even though some aspects aren't completely deterministic - question: suppose we start with a machine twice, both with the same starting conditions => will same things always happen? - maybe, it's hard to get the exact same starting conditions! (e.g. some electronic gates are warmer, so they run a little faster) - distinction between micro and macro level behavior - micro is irreproducible - macro is reproducible - question: why permit cooperation? - share resources (many tellers, one bank database) - do things faster (execute in parallel) - modularity (break problem down into many possibly parallel pieces, easier for debugging) counting contest => A increments i until 10, B decrements i until -10, who finishes first? - assume reading and assignment are atomic - shared state is variable i - one answer: nobody ever wins, i just keeps going up and down - another answer: somebody wins, but it's underministic - we want deterministic results! - multiprocessing (diff processes, shared processor) and multiprogramming (diff processors, shared memory) both complicated - can never assume that there won't be an interrupt between two sequential events - no such thing as uniprogramming processor, becaues IO devices behave as process atomic processes - either happen or didn't happen (in entirety) - loads/assignments are atomic - arrays are a sequence of operations that can be interrupted in the middle, so not atomic - uniprocessors with interrupts turned off makes system almost atomic (exception is traps) - given atomic operations, can construct larger atomic operations for parallel programs - atomic ops are built into hardware to make synchronization easier milk problem - shared state is shopping for milk - evaluation of solution attempts - 1. if both check for milk before anyone leaves a note, we have too much milk - problem is sequence of ops can be interrupted at any time - 2. works, but assumes reliable roommate - if B dies, then note will never be removed - 3. if both leave notes before checking each other's notes, then nobody buys any milk - starvation - 4. works, but assumes reliable roommate - if B dies after leaving note, A waits forever - disadvantage is A's busy waiting - solution not immediately adaptable to adding a 3rd roommate - conditions for correctness - if there is milk, someone will buy it (without deadlocks) - at most one unit of milk is purchased - solution is complicated! we need something more powerful - synchronization uses atomic processes to ensure correct operation of cooperating processes (milk buying protocol) - mutual exclusion means one process can execute chunk of ops at a time (going shopping) - critical section contains the operation we want to make atomic (shopping) - locking mechanism locks before whatever we use or do, and unlocks when we are done - processes wait if lock is already set semaphores - types - (P) gain control of lock by decrementing (as long as it's > 0, else wait) - (V) release lock by incrementing - binary semaphores only use 0 and 1 - used in 2 ways - mutual exclusion => ensure only one process accessed shared info at a time, always are binary semaphores - scheduling => permit processes to wait for certain events, not necessarily binary semaphores - not built into hardware - most computer have hardware synchronization op out of which you can build a semaphore - releasing, scheduling processes is very complicated for hardware