Chapter 6 Processes and Operating Systems

1. Chapter 6Processes and Operating Systems 金仲達教授 清華大學資訊工程學系 (Slides are taken from the textbook slides)

2. Overview • Processes • Context switching • Operating systems • Scheduling policies • Interprocess communication • Evaluation and optimization • Design example: telephone answering machine

3. Introduction • When multiple operations must be performed at widely varying times, a single program can easily become too complex • Two abstractions to build complex applications: • process: defines the state of an executing program=> compartmentalize functions • operating system: provides mechanism for switching execution between the processes=> encapsulate control for switching processes • Allowing • switching state of processor between multiple tasks • building applications with more complex functionality and greater flexibility to satisfy timing requirements

4. Why multiple processes? • Need to structure programs to perform multiple tasks • Processes help us manage timing complexity: • receive and send data at multiple rates, e.g., multimedia, automotive • asynchronous input, e.g., user interfaces, communication systems • Multirate systems make meeting timing requirements even more complex: • certain operations must be executed periodically , and each is executed at its own rate

5. Example: engine control • Tasks: • spark control • crankshaft sensing • fuel/air mixture • oxygen sensor • Kalman filter • To fire spark plugperiodically, setthrottle, adjustfuel/air mixture, etc. engine controller

6. Life without processes • Code turns into a mess: • interruptions of onetask for another • spaghetti code A_code(); … B_code(); … if (C) C_code(); … A_code(); … switch (x) { case C: C(); case D: D(); ... A time B C A C

7. ADR r14,co2a co1a … ADR r13,co1b MOV r15,r14 co1b … ADR r13,co1c MOV r15,r14 co1c ... co2a … ADR r14,co2b MOV r15,r13 co2b … ADR r14,co2c MOV r15,r13 co2c … Early multitasking: co-routines Co-routine 1 Co-routine 2 r13: holds return address for co-routine 1 r14: holds return address for co-routine 2

8. Co-routine methodology • A co-routine has several different entry points • give hooks for nonhierarchical calls and returns • Like subroutine, but caller determines the return address • Co-routines voluntarily give up control to other co-routines • Pattern of control transfers is embedded in the code => difficult to handle timing requirements

9. Processes • A process is a unique execution of a program. • A process is defined by its code and data • Several copies of a program may run simultaneously or at different times • A process has its own state: • registers • memory • The operating system manages processes

10. Processes and CPUs • Activation record: copy of process state • Context switch: • current CPU contextgoes out • new CPU contextgoes in process 1 PC registers process 2 CPU ... memory

11. Terms • Thread = lightweight process: a process that shares memory space with other processes • avoid the cost and complexity of memory management units that provide strict separation between memory spaces • Reentrancy: ability of a program to be executed several times with the same results.

12. Processes in POSIX • Create a process with fork(): • Two processes are exactly the same in code and data, except the return value of fork() process a process a (parent) process a (child)

13. fork() • The fork system call creates a child process: childid = fork(); if (childid == 0) { /* child operations */ } else {/* childid = child proc id */ /* parent operations */ }

14. execv() • Overlays child code: childid = fork(); if (childid == 0) { execv(“mychild”,childargs); perror(“execv”); exit(1); } file with child code

15. wait() • Parent waits for the child to terminate and release all resources: childid = fork(); if (childid == 0) { /* child things */ } else { /* parent things */ wait(&cstatus); exit(0); }

16. Overview • Processes • Context switching • Operating systems • Scheduling policies • Interprocess communication • Evaluation and optimization • Design example: telephone answering machine

17. Context switching • Moving CPU from one executing process to another • Bug-free: process not know it was stopped • fast • Who controls when the context is switched? • How is the context switched?

18. Co-operative multitasking • A restricted form of context switches • One process gives up CPU to another voluntarily • Improvement on co-routines: • hides context switching mechanism; • still relies on processes to give up CPU. • Each process allows a context switch by calling cswitch() • A scheduler chooses which process runs next

19. Cooperative multitasking processes If (x>2) sub1(y); else sub2(y,z); cswitch(); proca(a,b,c); Process 1 proc_data(r,s,t); cswitch(); if (val1==3) abc(val2); Process 2 save_state(current); p=choose_process(); load_and_go(p); Scheduler

20. Context switching in ARM • Save and restore process contexts current process context block CPSR r13 PC r0 CPU r14 Memory

21. Save old process: STMIA r13,{r0-r14}^ MRS r0,SPSR STMDB r13,{r0,r15} Start new process: ADR r0,NEXTPROC LDR r13,[r0] LDMDB r13,{r0,r14} MSR SPSR,r0 LDMIA r13,{r0-r14}^ MOVS pc,r14 Cooperative context switching in ARM STMIA r13,{r0-r14}^: store all registers to memory pointed by r13 MRS r0,SPSR: save content of SPSR to r0 STMDB r13,{r0,r15}: save SPSR and PC to memory pointed by r13 NEXTPROC: variable pointing to next process’s context block

22. Problems with co-operative multitasking • Programming errors can keep other processes out, because the CPU must be voluntarily given up by a process • process never gives up CPU • process waits too long to switch, missing input process2() { x = global1; /* input to process */ while (x<500) x = aproc(global2); switch(); } x may always <500 and process never switch

23. Preemptive multitasking • Most powerful form of multitasking: • OS controls when contexts switches • OS determines what process runs next • Take advantage of interrupt mechanism • Use timer to interrupt OS, switch contexts • Reduce consequence of programming errors • Allocate CPU time more efficiently interrupt CPU timer

24. Preemptive context switching • Timer interrupt gives control to OS, which saves interrupted process’s state in activation record • OS chooses next process to run. • OS installs desired activation record as current CPU state. interrupt interrupt P1 OS P1 OS P2 time

25. Processes and UML • A process is an active class, independent thread of control • Signal: object that is passed between processes for active communication processClass1 myAttributes acomm: datasignal myOperations() start resume Signals

26. Designing with active objects • Can mix normal and active objects: p1: processClass1 a: rawMsg w: wrapperClass ahat: fullMsg master: masterClass

27. Overview • Processes • Context switching • Operating systems • Scheduling policies • Interprocess communication • Evaluation and optimization • Design example: telephone answering machine

28. Operating systems • The operating system controls resources: • who gets the CPU • when I/O takes place • how much memory is allocated • The most important resource is the CPU itself • CPU access controlled by the scheduler • OS simplifies the control code required to coordinate processes • scheduling is centralized

29. Process state • A process can be in one of three states: • executing on the CPU • ready to run • waiting for data • Use process priorities tochoose next executingprocess executing gets data and CPU gets CPU preempted needs data gets data ready waiting needs data

30. Priority-driven scheduling • Each process has a priority. • CPU goes to highest-priority process that is ready. • Priorities determine scheduling policy: • fixed priority; • time-varying priorities.

31. Priority-driven scheduling example • Rules: • each process has a fixed priority (1 highest); • highest-priority ready process gets CPU; • process continues until done. • Processes • P1: priority 1, execution time 10 • P2: priority 2, execution time 30 • P3: priority 3, execution time 20

32. P3 ready t=18 P2 ready t=0 P1 ready t=15 interrupt P2 Priority-driven scheduling example P2 P1 P2 P3 30 60 0 10 20 40 50 time

33. Operating system structure • OS needs to keep track of: • process priorities; • scheduling state; • process activation record. • Processes may be created: • statically before system starts; • dynamically during execution (process state records kept in a linked list) • When some events occur aperiodically and infrequently, it is reasonable to create a process to handle the event when it occurs

34. Operating system structure • OS generally executes in the protected mode • ARM uses SWI (software interrupt) to provide OS access • Puts CPU into the supervisor mode • Exception vector table directs execution to the proper place in OS • The one argument passes a parameter to the OS

35. Process timing requirements • Process initiation disciplines: • Periodic process: executes on (almost) every period. • Aperiodic process: executes on demand. • Analyzing aperiodic process sets is harder---must consider worst-case combinations of process activations.

36. Timing requirements on processes • Period: interval between process activations. • Rate requirement: how quickly processes must be initiated • Inverse gives the initiation interval • Initiation time: time at which process goes from waiting to ready. • Deadline: time at which process must finish.

37. Timing requirements Deadline Aperiodic process time P1 Initiating event Deadline Periodic process (initiatedat periodstart) time P1 Period Deadline Periodic process time P1 Initiating event Period

38. Timing violations • What happens if a process doesn’t finish by its deadline? • Hard deadline: system fails if missed. • Soft deadline: user may notice, but system doesn’t necessarily fail.

39. Example: Space Shuttle software error • Space Shuttle’s first launch was delayed by a software timing error: • Primary control system PASS and backup system BFS. • BFS failed to synchronize with PASS. • Change to one routine added delay that threw off start time calculation. • 1 in 67 chance of timing problem.

40. Interprocess communication • Interprocess communication (IPC): OS provides mechanisms so that processes can pass data. • Two types of semantics: • blocking: sending process waits for response; • non-blocking: sending process continues.

41. IPC styles • Shared memory: • processes have some memory in common; • must cooperate to avoid destroying/missing messages. • Message passing: • processes send messages along a communication channel---no common address space • They are logically equivalent

42. Shared memory • Shared memory on a bus: • Need a flag to tell one CPU when the data from the other CPU is ready • Uni-directional flag: easy with a memory write • Problem with bi-directional flag memory CPU 1 CPU 2

43. Race condition in shared memory • Problem when two CPUs try to write the same location: • CPU 1 reads flag and sees 0. • CPU 2 reads flag and sees 0. • CPU 1 sets flag to one and writes location. • CPU 2 sets flag to one and overwrites location.

44. Atomic test-and-set • Problem can be solved with an atomic test-and-set over the bus: • single bus operation reads memory location, tests it, writes it. • ARM test-and-set provided by SWP Rd,Rm,Rn: • Memory pointed by Rn is loaded into Rd and Rm is written to Rn ADR r0,SEMAPHORE LDR r1,#1 GETFLAG SWP r1,r1,[r0] BNZ GETFLAG

45. Critical regions • Critical region: section of code that cannot be interrupted by another process. • Examples: writing shared memory, accessing I/O device • Controlling access to critical region using semaphores: • Get access to semaphore with P() • Perform critical region operations • Release semaphore with V() • P() and V() can be implemented with test-and-set

46. message Message passing • Message passing on a network: • Messages stored at endpoints, not comm link • Good for applications with autonomic components, specially for those operate at different rates CPU 1 Message box Message Box CPU 2

47. Process data dependencies • Express relationships of processes running at the same rate • One process may not be ableto start until dependingones finish • Dependencies form a partialordering of process execution • Data dependencies defined ina directed acyclic graph, task graph P1 P2 P3 P4

48. Other operating system functions • The role of OS may be viewed as managing shared resources • Date/time • File system: for organizing large data sets, even without hard disks • Networking • Security • Debugging facility

49. Overview • Processes • Context switching • Operating systems • Scheduling policies • Interprocess communication • Evaluation and optimization • Design example: telephone answering machine

50. Embedded vs. general-purpose scheduling • Workstations try to avoid starving processes of CPU access. • Fairness = access to CPU. • Embedded systems must meet deadlines. • Low-priority processes may not run for a long time