Operating Systems: - 6.004

Timesharing EfficincyPROCESS0SchedulerPROCESS1Suppose Scheduler overhead is Sseconds, process quantum is Qseconds. What fraction of CPU is“useful work”?ANS: _______________Suppose each process takes Tseconds in “Batch” mode. Whatsthe total waiting time in BATCH(for BOTH processes)?ANS: ______________________Whats the total waiting timeusing timesharing?ANS: ______________________6.004 Fall ‘97... L49 12/2 4

Is Timesharing REALLYsuch a good idea???YES. But ONLY WHEN there’s_______________________________________!Otherwise, we’d be better off using batch processing!6.004 Fall ‘97... L49 12/2 5

stub:ST(r0, User)ST(r1, User+4)...ST(r30, User+30*4)call(C_Handler)LD(User, r0)LD(User+4, r1)...LD(User+30*4, r30)JMP(XP)Handler CodingC_Handler(){ TOD = TOD+1;}Variants:• Don’t save/restore ALL state, esp. for trivial handlers!• Save/Restore state directly into ProcTbl[Cur], instead ofonto stack (making Scheduler trivial!!!)• Switch to KERNEL STACK on interrupt.WHY? ________________________________6.004 Fall ‘97... L49 12/2 6

Device Handlers RevisitedRecall our keyboard SVC handler (slightly modified, egto support Virtual Keyboard):ReadCh_h(){ int kbdnum = ProcTbl[Cur].DPYNum;if (BufferEmpty(kbdnum)){ User.Regs[XP] = User.Regs[XP]-4;}elseUser.Regs[0] = ReadInputBuffer(kbdnum);}Hmmm... my process will waste ________________________if its waiting for input during my 2.5-hour lunch!6.004 Fall ‘97... L49 12/2 7

Smarter Device I/OBETTER: On I/O wait, YIELD remainder of quantum:ReadCh_h(){ int kbdnum = ProcTbl[Cur].DPYNum;if (BufferEmpty(kbdnum)){ User.Regs[XP] = User.Regs[XP]-4;Scheduler();}elseUser.Regs[0] = ReadInputBuffer(kbdnum);}Now, with N other runing processesmy waiting process uses about ________________________of the CPU cycles!6.004 Fall ‘97... L49 12/2 8

BETA micro-OS DemoP0while (){ GetKeySend}P1while (){ Rcv()TranslateWrCh}P2while (){ Count =Count+1;Yield();}STACKSTACKint count=0;STACKKernelSTACKUser:ProcTbl:MStateMStateMStateMStateSVC Handlers:GetKey(), WrCh()Wait(s), Signal(S)Yield()6.004 Fall ‘97... L49 12/2 9

Sophisticated SchedulingTo improve efficiency further, we can avoid schedulingprocesses in prolonged I/O wait:• Processes can be in ACTIVE or WAITING (“sleeping”) states;• Scheduler cycles among ACTIVE PROCESSES only;• Active process moves to WAITING status when it tries to read acharacter and buffer is empty;• Waiting processes each contain a code (eg, in PDB) designatingwhat they are waiting for (eg, keyboard N);• Device interrupts (eg, on keyboard N) move any processes waitingon that device to ACTIVE state.UNIX kernel utilities:• sleep(reason) - Puts CurProc to sleep. “Reason” is an arbitrarybinary value giving a condition for reactivation.• wakeup(reason) - Makes active any process in sleep(reason).6.004 Fall ‘97... L49 12/2 10

Other Scheduling HacksDemand Paging Heuristics:Split memory equally among N processes? Often:THRASHING!BETTER: Choose a few processes whose working sets fit intomemory, run them for a (longish) while, then pick anotherfew, etc.Priorities:Give each process a priority, run it preferentially overprocesses with lower priorities.LLL “free market” System: user picks a REAL priority P, pays$P/second for CPU time.6.004 Fall ‘97... L49 12/2 11

UNIX Process Management Semanticspid = fork() - create a new process“clones” current process, duplicating its state & memoryreturns 0 to child process, nonzero Process ID to parentexit(code) - process suicidecauses process to die, passing code to parent.kill(pid) - terminate a processForces process to exit involuntarily, with error statuspid = wait() - wait for child to exitreturns ID of next exiting process (may wait)6.004 Fall ‘97... L49 12/2 12

Typical UNIX child process handlingProcess-level Parallelism...if (fork() == 0){ DoThing1(); /* CHILD process */exit(); }else{ DoThing2(); /* PARENT process */wait(); }...EXAMPLES:Terminal Program: Parent copies data from keyboard to serialport; Child copies data from serial port to screen.Compilation: Child runs pre-processor, Parent runs compilerHeuristic Search: Child tries to prove hypothesis, Parent tries todisprove itNEED: Inter-process COMMUNICATION, SYNCHRONIZATION!6.004 Fall ‘97... L49 12/2 13

Other OS FunctionsFile System - (mostly) sequential access to data• fid = open(“File Name”, “r”);• read(fid, address, nbytes); write(fid, address, nbytes);• seek(fid, offset)Window System - Manage & multiplex display screenResource Management - RAM, disk, processesInter-Process Communication• Issue: communication semantics. Some Choices:– SHARED MEMORY. Overlapping contexts allow severalprocesses to access same physical pages.– Pipes, providing virtual file I/O connections between pairs ofprocesses (using open, read, etc SVCs)6.004 Fall ‘97... L49 12/2 14

Shared PagesConsider two processes running same program, sharing a page:P 0 VMPhysicalContext 0 Memory Context 1P 1 VM“pure” code: Read OnlyStack: Private Read/WritePRIVATE R/W DataSHARED R/W Data6.004 Fall ‘97... L49 12/2 15

OS-Level Communications:a brief history1963: CTSS. Advent of Timesharing• Separate USER memory, process swapping, simple files.Late 60s: MULTICS. Attempt to unify communications.• Virtual Memory, contexts• Memory semantics as unifying theme: mapped-in files.Early 70s: UNIX. Another unification attempt.• Simple memory model, small processes• File system semantics as unifying theme: “Pipes” betweenprocesses, virtual file I/O.1980s: Networks of workstations.• APOLLO: Memory access as communication basis• UNIX: File access as communication basis, but big VM too.1990s: Still have both MEMORY and FILE semantics, BECAUSEthey address different ________________ properties!6.004 Fall ‘97... L49 12/2 16

Minimizing the KernelOld-style OS:BIG Collection ofWIRED-IN servicesvs.Micro-Kernel:Services moved to processesUSERUSERPGMPGM1USER USERPGM PGM1 NWindowSystemFileSystemKernelProcessStuffWindowSystemFileSystemI.P.CI/ODriversNKernel I/OADVANTAGES:ProcessStuffDrivers1. ____________________I.P.C2. ____________________6.004 Fall ‘97... L49 12/2 17

The Future of Operating SystemsIs there one?Traditional operating system boundaries are changing,and traditional OS technology is being absorbed by• Architecture: Extensions to the MACHINE MODEL.– API (Application Program Interface)– Internal communication models (Remote Procedure Calls,Messages, Shared memory, ...)• User Interfaces:– Window systems & GUIs– Multimedia• Network communications:– The Web as GUI standard– Browser/plugins as new OS environment... perhaps you’re the last generation of students tobe offered a course on Operating Systems!6.004 Fall ‘97... L49 12/2 18

Next Lecture:some parallel processing issues...6.004 Fall ‘97... L49 12/2 19