1. © 2000 Morgan Kaufman Overheads for Computers as Components Processes and operating systems zMotivation for processes. zThe process abstraction. zContext switching. zMultitasking. zProcesses and UML.

2. © 2000 Morgan Kaufman Overheads for Computers as Components Why multiple processes? zProcesses help us manage timing complexity: ymultiple rates xmultimedia xautomotive yasynchronous input xuser interfaces xcommunication systems

3. © 2000 Morgan Kaufman Overheads for Computers as Components Example: engine control zTasks: yspark control ycrankshaft sensing yfuel/air mixture yoxygen sensor yKalman filter engine controller

4. © 2000 Morgan Kaufman Overheads for Computers as Components Life without processes zCode turns into a mess: yinterruptions of one task for another yspaghetti code time A B C A C A_code(); … B_code(); … if (C) C_code(); … A_code(); … switch (x) { case C: C(); case D: D();...

5. © 2000 Morgan Kaufman Overheads for Computers as Components Co-routines ADR r14,co2a co1a … ADR r13,co1b MOV r15,r14 co1b … ADR r13,co1c MOV r15,r14 co1c... co2a … ADR r13,co2b MOV r15,r13 co2b … ADR r13,co2c MOV r15,r13 co2c … Co-routine 1 Co-routine 2

6. © 2000 Morgan Kaufman Overheads for Computers as Components Co-routine methodology zLike subroutine, but caller determines the return address. zCo-routines voluntarily give up control to other co-routines. zPattern of control transfers is embedded in the code.

7. © 2000 Morgan Kaufman Overheads for Computers as Components Processes zA process is a unique execution of a program. ySeveral copies of a program may run simultaneously or at different times. zA process has its own state: yregisters; ymemory. zThe operating system manages processes.

8. © 2000 Morgan Kaufman Overheads for Computers as Components Processes and CPUs zActivation record: copy of process state. zContext switch: ycurrent CPU context goes out; ynew CPU context goes in. CPU PC registers process 1 process 2... memory

9. © 2000 Morgan Kaufman Overheads for Computers as Components Terms zThread = lightweight process: a process that shares memory space with other processes. zReentrancy: ability of a program to be executed several times with the same results.

10. © 2000 Morgan Kaufman Overheads for Computers as Components Context switching zWho controls when the context is switched? zHow is the context switched?

11. © 2000 Morgan Kaufman Overheads for Computers as Components Co-operative multitasking zImprovement on co-routines: yhides context switching mechanism; ystill relies on processes to give up CPU. zEach process allows a context switch at cswitch() call. zSeparate scheduler chooses which process runs next.

12. © 2000 Morgan Kaufman Overheads for Computers as Components Problems with co- operative multitasking zProgramming errors can keep other processes out: yprocess never gives up CPU; yprocess waits too long to switch, missing input.

13. © 2000 Morgan Kaufman Overheads for Computers as Components Context switching zMust copy all registers to activation record, keeping proper return value for PC. zMust copy new activation record into CPU state. zHow does the program that copies the context keep its own context?

14. © 2000 Morgan Kaufman Overheads for Computers as Components Context switching in ARM zSave old process: STMIA r13,{r0-r14}^ MRS r0,SPSR STMDB r13,{r0,r15} z Start new process: ADR r0,NEXTPROC LDR r13,[r0] LDMDB r13,{r0,r14} MSR SPSR,r0 LDMIA r13,{r0-r14}^ MOVS pc,r14

15. © 2000 Morgan Kaufman Overheads for Computers as Components Preemptive multitasking zMost powerful form of multitasking: yOS controls when contexts switches; yOS determines what process runs next. zUse timer to call OS, switch contexts: CPU timer interrupt

16. © 2000 Morgan Kaufman Overheads for Computers as Components Flow of control with preemption time P1OSP1OSP2 interrupt

17. © 2000 Morgan Kaufman Overheads for Computers as Components Preemptive context switching zTimer interrupt gives control to OS, which saves interrupted process’s state in an activation record. zOS chooses next process to run. zOS installs desired activation record as current CPU state.

18. © 2000 Morgan Kaufman Overheads for Computers as Components Why not use interrupts? zWe could change the interrupt vector at every period, but: ywe would need management code anyway; ywe would have to know the next period’s process at the start of the current process.

19. © 2000 Morgan Kaufman Overheads for Computers as Components Processes and UML zA process is an active class---independent thread of control. processClass1 myOperations() start resume myAttributes Signals

20. © 2000 Morgan Kaufman Overheads for Computers as Components UML signals zSignal: object that is passed between processes for active communication: acomm: datasignal

21. © 2000 Morgan Kaufman Overheads for Computers as Components Designing with active objects zCan mix normal and active objects: p1: processClass1 master: masterClass w: wrapperClass a: rawMsg ahat: fullMsg

22. © 2000 Morgan Kaufman Overheads for Computers as Components Processes and operating systems zOperating systems.

23. © 2000 Morgan Kaufman Overheads for Computers as Components Operating systems zThe operating system controls resources: ywho gets the CPU; ywhen I/O takes place; yhow much memory is allocated. zThe most important resource is the CPU itself. yCPU access controlled by the scheduler.

24. © 2000 Morgan Kaufman Overheads for Computers as Components Process state zA process can be in one of three states: yexecuting on the CPU; yready to run; ywaiting for data. executing readywaiting gets data and CPU needs data gets data needs data preempted gets CPU

25. © 2000 Morgan Kaufman Overheads for Computers as Components Operating system structure zOS needs to keep track of: yprocess priorities; yscheduling state; yprocess activation record. zProcesses may be created: ystatically before system starts; ydynamically during execution.

26. © 2000 Morgan Kaufman Overheads for Computers as Components Embedded vs. general- purpose scheduling zWorkstations try to avoid starving processes of CPU access. yFairness = access to CPU. zEmbedded systems must meet deadlines. yLow-priority processes may not run for a long time.

27. © 2000 Morgan Kaufman Overheads for Computers as Components Priority-driven scheduling zEach process has a priority. zCPU goes to highest-priority process that is ready. zPriorities determine scheduling policy: yfixed priority; ytime-varying priorities.

28. © 2000 Morgan Kaufman Overheads for Computers as Components Priority-driven scheduling example zRules: yeach process has a fixed priority (1 highest); yhighest-priority ready process gets CPU; yprocess continues until done. zProcesses yP1: priority 1, execution time 10 yP2: priority 2, execution time 30 yP3: priority 3, execution time 20

29. © 2000 Morgan Kaufman Overheads for Computers as Components Priority-driven scheduling example time P2 ready t=0P1 ready t=15 P3 ready t=18 0 30 1020 60 4050 P2 P1P3

30. © 2000 Morgan Kaufman Overheads for Computers as Components The scheduling problem zCan we meet all deadlines? yMust be able to meet deadlines in all cases. zHow much CPU horsepower do we need to meet our deadlines?

31. © 2000 Morgan Kaufman Overheads for Computers as Components Process initiation disciplines zPeriodic process: executes on (almost) every period. zAperiodic process: executes on demand. zAnalyzing aperiodic process sets is harder- --must consider worst-case combinations of process activations.

32. © 2000 Morgan Kaufman Overheads for Computers as Components Timing requirements on processes zPeriod: interval between process activations. zInitiation interval: reciprocal of period. zInitiation time: time at which process becomes ready. zDeadline: time at which process must finish.

33. © 2000 Morgan Kaufman Overheads for Computers as Components Timing violations zWhat happens if a process doesn’t finish by its deadline? yHard deadline: system fails if missed. ySoft deadline: user may notice, but system doesn’t necessarily fail.

34. © 2000 Morgan Kaufman Overheads for Computers as Components Example: Space Shuttle software error zSpace Shuttle’s first launch was delayed by a software timing error: yPrimary control system PASS and backup system BFS. yBFS failed to synchronize with PASS. yChange to one routine added delay that threw off start time calculation. y1 in 67 chance of timing problem.

35. © 2000 Morgan Kaufman Overheads for Computers as Components Interprocess communication zInterprocess communication (IPC): OS provides mechanisms so that processes can pass data. zTwo types of semantics: yblocking: sending process waits for response; ynon-blocking: sending process continues.

36. © 2000 Morgan Kaufman Overheads for Computers as Components IPC styles zShared memory: yprocesses have some memory in common; ymust cooperate to avoid destroying/missing messages. zMessage passing: yprocesses send messages along a communication channel---no common address space.

37. © 2000 Morgan Kaufman Overheads for Computers as Components Shared memory zShared memory on a bus: CPU 1CPU 2 memory

38. © 2000 Morgan Kaufman Overheads for Computers as Components Race condition in shared memory zProblem when two CPUs try to write the same location: yCPU 1 reads flag and sees 0. yCPU 2 reads flag and sees 0. yCPU 1 sets flag to one and writes location. yCPU 2 sets flag to one and overwrites location.

39. © 2000 Morgan Kaufman Overheads for Computers as Components Atomic test-and-set zProblem can be solved with an atomic test-and-set: ysingle bus operation reads memory location, tests it, writes it. zARM test-and-set provided by SWP: ADR r0,SEMAPHORE LDR r1,#1 GETFLAG SWP r1,r1,[r0] BNZ GETFLAG

40. © 2000 Morgan Kaufman Overheads for Computers as Components Critical regions zCritical region: section of code that cannot be interrupted by another process. zExamples: ywriting shared memory; yaccessing I/O device.

41. © 2000 Morgan Kaufman Overheads for Computers as Components Semaphores zSemaphore: OS primitive for controlling access to critical regions. zProtocol: yGet access to semaphore with P(). yPerform critical region operations. yRelease semaphore with V().

42. © 2000 Morgan Kaufman Overheads for Computers as Components Message passing zMessage passing on a network: CPU 1CPU 2 message

43. © 2000 Morgan Kaufman Overheads for Computers as Components Process data dependencies zOne process may not be able to start until another finishes. zData dependencies defined in a task graph. zAll processes in one task run at the same rate. P1P2 P3 P4

44. © 2000 Morgan Kaufman Overheads for Computers as Components Other operating system functions zDate/time. zFile system. zNetworking. zSecurity.

45. © 2000 Morgan Kaufman Overheads for Computers as Components Processes and operating systems zScheduling policies: yRMS; yEDF. zScheduling modeling assumptions. zInterprocess communication. zPower management.

46. © 2000 Morgan Kaufman Overheads for Computers as Components Metrics zHow do we evaluate a scheduling policy: yAbility to satisfy all deadlines. yCPU utilization---percentage of time devoted to useful work. yScheduling overhead---time required to make scheduling decision.

47. © 2000 Morgan Kaufman Overheads for Computers as Components Rate monotonic scheduling zRMS (Liu and Layland): widely-used, analyzable scheduling policy. zAnalysis is known as Rate Monotonic Analysis (RMA).

48. © 2000 Morgan Kaufman Overheads for Computers as Components RMA model zAll process run on single CPU. zZero context switch time. zNo data dependencies between processes. zProcess execution time is constant. zDeadline is at end of period. zHighest-priority ready process runs.

49. © 2000 Morgan Kaufman Overheads for Computers as Components Process parameters  T i is computation time of process i;  i is period of process i. period  i Pi computation time T i

50. © 2000 Morgan Kaufman Overheads for Computers as Components Rate-monotonic analysis zResponse time: time required to finish process. zCritical instant: scheduling state that gives worst response time. zCritical instant occurs when all higher- priority processes are ready to execute.

51. © 2000 Morgan Kaufman Overheads for Computers as Components Critical instant P4 P3 P2 P1 critical instant P1 P2 P3 interfering processes

52. © 2000 Morgan Kaufman Overheads for Computers as Components RMS priorities zOptimal (fixed) priority assignment: yshortest-period process gets highest priority; ypriority inversely proportional to period; ybreak ties arbitrarily. zNo fixed-priority scheme does better.

53. © 2000 Morgan Kaufman Overheads for Computers as Components RMS example time 0510 P2 period P1 period P1 P2 P1

54. © 2000 Morgan Kaufman Overheads for Computers as Components RMS CPU utilization zUtilization for n processes is   i T i /  i zAs number of tasks approaches infinity, maximum utilization approaches 69%.

55. © 2000 Morgan Kaufman Overheads for Computers as Components RMS CPU utilization, cont’d. zRMS cannot use 100% of CPU, even with zero context switch overhead. zMust keep idle cycles available to handle worst-case scenario. zHowever, RMS guarantees all processes will always meet their deadlines.

56. © 2000 Morgan Kaufman Overheads for Computers as Components RMS implementation zEfficient implementation: yscan processes; ychoose highest-priority active process.

57. © 2000 Morgan Kaufman Overheads for Computers as Components Earliest-deadline-first scheduling zEDF: dynamic priority scheduling scheme. zProcess closest to its deadline has highest priority. zRequires recalculating processes at every timer interrupt.

58. © 2000 Morgan Kaufman Overheads for Computers as Components EDF analysis zEDF can use 100% of CPU. zBut EDF may fail to miss a deadline.

59. © 2000 Morgan Kaufman Overheads for Computers as Components EDF implementation zOn each timer interrupt: ycompute time to deadline; ychoose process closest to deadline. zGenerally considered too expensive to use in practice.

60. © 2000 Morgan Kaufman Overheads for Computers as Components Fixing scheduling problems zWhat if your set of processes is unschedulable? yChange deadlines in requirements. yReduce execution times of processes. yGet a faster CPU.

61. © 2000 Morgan Kaufman Overheads for Computers as Components Priority inversion zPriority inversion: low-priority process keeps high-priority process from running. zImproper use of system resources can cause scheduling problems: yLow-priority process grabs I/O device. yHigh-priority device needs I/O device, but can’t get it until low-priority process is done. zCan cause deadlock.

62. © 2000 Morgan Kaufman Overheads for Computers as Components Solving priority inversion zGive priorities to system resources. zHave process inherit the priority of a resource that it requests. yLow-priority process inherits priority of device if higher.

63. © 2000 Morgan Kaufman Overheads for Computers as Components Data dependencies zData dependencies allow us to improve utilization. yRestrict combination of processes that can run simultaneously. zP1 and P2 can’t run simultaneously. P1 P2

64. © 2000 Morgan Kaufman Overheads for Computers as Components Context-switching time zNon-zero context switch time can push limits of a tight schedule. zHard to calculate effects---depends on order of context switches. zIn practice, OS context switch overhead is small.

65. © 2000 Morgan Kaufman Overheads for Computers as Components Interprocess communication zOS provides interprocess communication mechanisms: yvarious efficiencies; ycommunication power.

66. © 2000 Morgan Kaufman Overheads for Computers as Components Signals zA Unix mechanism for simple communication between processes. zAnalogous to an interrupt---forces execution of a process at a given location. yBut a signal is caused by one process with a function call. zNo data---can only pass type of signal.

67. © 2000 Morgan Kaufman Overheads for Computers as Components Signals in UML zMore general than Unix signal---may carry arbitrary data: > aSig p : integer someClass sigbehavior() >

68. © 2000 Morgan Kaufman Overheads for Computers as Components Evaluating performance zMay want to test: ycontext switch time assumptions; yscheduling policy. zCan use OS simulator to exercise process set, trace system behavior.

69. © 2000 Morgan Kaufman Overheads for Computers as Components Processes and caches zProcesses can cause additional caching problems. yEven if individual processes are well- behaved, processes may interfere with each other. zWorst-case execution time with bad behavior is usually much worse than execution time with good cache behavior.

70. © 2000 Morgan Kaufman Overheads for Computers as Components Power optimization zPower management: determining how system resources are scheduled/used to control power consumption. zOS can manage for power just as it manages for time. zOS reduces power by shutting down units. yMay have partial shutdown modes.

71. © 2000 Morgan Kaufman Overheads for Computers as Components Power management and performance zPower management and performance are often at odds. zEntering power-down mode consumes yenergy, ytime. zLeaving power-down mode consumes yenergy, ytime.

72. © 2000 Morgan Kaufman Overheads for Computers as Components Simple power management policies zRequest-driven: power up once request is received. Adds delay to response. zPredictive shutdown: try to predict how long you have before next request. yMay start up in advance of request in anticipation of a new request. yIf you predict wrong, you will incur additional delay while starting up.

73. © 2000 Morgan Kaufman Overheads for Computers as Components Probabilistic shutdown zAssume service requests are probabilistic. zOptimize expected values: ypower consumption; yresponse time. zSimple probabilistic: shut down after time T on, turn back on after waiting for T off.

74. © 2000 Morgan Kaufman Overheads for Computers as Components Advanced Configuration and Power Interface zACPI: open standard for power management services. Hardware platform device drivers ACPI BIOS OS kernel applications power management

75. © 2000 Morgan Kaufman Overheads for Computers as Components ACPI global power states zG3: mechanical off zG2: soft off xS1: low wake-up latency with no loss of context xS2: low latency with loss of CPU/cache state xS3: low latency with loss of all state except memory xS4: lowest-power state with all devices off zG1: sleeping state zG0: working state