Processes Control Block (Operating System)

Software Engineer em FUUAST
29 de Oct de 2013

Mais conteúdo relacionado


Processes Control Block (Operating System)

  1. OPERATING SYSTEMS PROCESS CONTROL BLOCK Software Engr. Imdad Manik 03007060570
  2. Role of the Process Control Block – Process Control block is used for : – storing the collection of information about the processes. – it is also called Data Structure – various information of PCB as following: i. Name of the process ii. State of the process mean Ready, Activate, Wait iii. Resources allocated to the process iv. Memory which is provided to the process v. Scheduling information vi. I /O devices used by the process vii.Process ID , given by the CPU when a process request for a service.
  3. Requirements of an Operating System • Fundamental Task: Process Management • The Operating System must – Interleave the execution of multiple processes – Allocate resources to processes, and protect the resources of each process from other processes, – Enable processes to share and exchange information, – Enable synchronization among processes.
  4. Concepts • From earlier chapters we saw: – Computer platforms consists of a collection of hardware resources – Computer applications are developed to perform some task – It is inefficient for applications to be written directly for a given hardware platform
  5. Concepts cont… – OS provides an interface for applications to use – OS provides a representation of resources that can be requested and accessed by application
  6. The OS Manages Execution of Applications • Resources are made available to multiple applications • The processor is switched among multiple application • The processor and I/O devices can be used efficiently
  7. What is a “process”? • A program in execution • An instance of a program running on a computer • The entity that can be assigned to and executed on a processor • A unit of activity characterized by the execution of a sequence of instructions, a current state, and an associated set of system instructions
  8. Process Elements • A process is comprised of: – Program code (possibly shared) – A set of data – A number of attributes describing the state of the process
  9. Process Elements • While the process is running it has a number of elements including – Identifier – State – Priority – Program counter – Memory pointers – Context data – I/O status information – Accounting information
  10. Process Control Block • Contains the process elements • Created and managed by the operating system • Allows support for multiple processes
  11. Trace of the Process • The behavior of an individual process is shown by listing the sequence of instructions that are executed • This list is called a Trace • Dispatcher is a small program which switches the processor from one process to another
  12. Process Execution • Consider three processes being executed • All are in memory (plus the dispatcher) • Lets ignore virtual memory for this.
  13. Trace from the processes point of view: • Each process runs to completion
  14. Trace from Processors point of view Timeout I/O
  15. Roadmap – How are processes represented and controlled by the OS. – Process states which characterize the behaviour of processes. – Data structures used to manage processes. – Ways in which the OS uses these data structures to control process execution. – Discuss process management in UNIX SVR4.
  16. Two-State Process Model • Process may be in one of two states – Running – Not-running
  17. Queuing Diagram Etc … processes moved by the dispatcher of the OS to the CPU then back to the queue until the task is competed
  18. Process Birth and Death Creation New batch job Interactive Login Created by OS to provide a service Termination Normal Completion Memory unavailable Protection error Spawned by existing Operator or OS process Intervention See tables 3.1 and 3.2 for more
  19. Process Creation • The OS builds a data structure to manage the process • Traditionally, the OS created all processes – But it can be useful to let a running process create another • This action is called process spawning – Parent Process is the original, creating, process – Child Process is the new process
  20. Process Termination • There must be some way that a process can indicate completion. • This indication may be: – A HALT instruction generating an interrupt alert to the OS. – A user action (e.g. log off, quitting an application) – A fault or error – Parent process terminating
  21. Five-State Process Model
  22. Using Two Queues
  23. Multiple Blocked Queues
  24. Suspended Processes • Processor is faster than I/O so all processes could be waiting for I/O – Swap these processes to disk to free up more memory and use processor on more processes • Blocked state becomes suspend state when swapped to disk • Two new states – Blocked/Suspend – Ready/Suspend
  25. One Suspend State
  26. Two Suspend States
  27. Reason for Process Suspension Reason Comment Swapping The OS needs to release sufficient main memory to bring in a process that is ready to execute. Other OS Reason OS suspects process of causing a problem. Interactive User Request e.g. debugging or in connection with the use of a resource. Timing A process may be executed periodically (e.g., an accounting or system monitoring process) and may be suspended while waiting for the next time. Parent Process Request A parent process may wish to suspend execution of a descendent to examine or modify the suspended process, or to coordinate the activity of various descendants. Table 3.3 Reasons for Process Suspension
  28. Roadmap – How are processes represented and controlled by the OS. – Process states which characterize the behaviour of processes. – Data structures used to manage processes. – Ways in which the OS uses these data structures to control process execution. – Discuss process management in UNIX SVR4.
  29. Processes and Resources
  30. Operating System Control Structures • For the OS is to manage processes and resources, it must have information about the current status of each process and resource. • Tables are constructed for each entity the operating system manages
  31. OS Control Tables
  32. Memory Tables • Memory tables are used to keep track of both main and secondary memory. • Must include this information: – Allocation of main memory to processes – Allocation of secondary memory to processes – Protection attributes for access to shared memory regions – Information needed to manage virtual memory
  33. I/O Tables • Used by the OS to manage the I/O devices and channels of the computer. • The OS needs to know – Whether the I/O device is available or assigned – The status of I/O operation – The location in main memory being used as the source or destination of the I/O transfer
  34. File Tables • These tables provide information about: – Existence of files – Location on secondary memory – Current Status – other attributes. • Sometimes this information is maintained by a file management system
  35. Process Tables • To manage processes the OS needs to know details of the processes – Current state – Process ID – Location in memory – etc • Process control block – Process image is the collection of program. Data, stack, and attributes
  36. Process Attributes • We can group the process control block information into three general categories: – Process identification – Processor state information – Process control information
  37. Process Identification • Each process is assigned a unique numeric identifier. • Many of the other tables controlled by the OS may use process identifiers to crossreference process tables
  38. Processor State Information • This consists of the contents of processor registers. – User-visible registers – Control and status registers – Stack pointers • Program status word (PSW) – contains status information – Example: the EFLAGS register on Pentium processors
  39. Pentium II EFLAGS Register Also see Table 3.6
  40. Process Control Information • This is the additional information needed by the OS to control and coordinate the various active processes. – See table 3.5 for scope of information
  41. Structure of Process Images in Virtual Memory
  42. Role of the Process Control Block • The most important data structure in an OS – It defines the state of the OS • Process Control Block requires protection – A faulty routine could cause damage to the block destroying the OS’s ability to manage the process – Any design change to the block could affect many modules of the OS
  43. Roadmap – How are processes represented and controlled by the OS. – Process states which characterize the behaviour of processes. – Data structures used to manage processes. – Ways in which the OS uses these data structures to control process execution. – Discuss process management in UNIX SVR4.
  44. Modes of Execution • Most processors support at least two modes of execution • User mode – Less-privileged mode – User programs typically execute in this mode • System mode – More-privileged mode – Kernel of the operating system
  45. Process Creation • Once the OS decides to create a new process it: – Assigns a unique process identifier – Allocates space for the process – Initializes process control block – Sets up appropriate linkages – Creates or expand other data structures
  46. Switching Processes • Several design issues are raised regarding process switching – What events trigger a process switch? – We must distinguish between mode switching and process switching. – What must the OS do to the various data structures under its control to achieve a process switch?
  47. When to switch processes A process switch may occur any time that the OS has gained control from the currently running process. Possible events giving OS control are: Mechanism Cause Use Interrupt External to the execution of the current instruction Reaction to an asynchronous external event Trap Associated with the execution of the current instruction Handling of an error or an exception condition Supervisor call Explicit request Call to an operating system function Table 3.8 Mechanisms for Interrupting the Execution of a Process
  48. Change of Process State … • The steps in a process switch are: 1. Save context of processor including program counter and other registers 2. Update the process control block of the process that is currently in the Running state 3. Move process control block to appropriate queue – ready; blocked; ready/suspend
  49. Change of Process State cont… 4. Select another process for execution 5. Update the process control block of the process selected 6. Update memory-management data structures 7. Restore context of the selected process
  50. Processes in Unix
  51. UNIX Process State Transition Diagram
  52. UNIX Process States
  53. A Unix Process • A process in UNIX is a set of data structures that provide the OS with all of the information necessary to manage and dispatch processes. • See Table 3.10 which organizes the elements into three parts: – user-level context, – register context, and – system-level context.
  54. Process Creation • Process creation is by means of the kernel system call,fork( ). • This causes the OS, in Kernel Mode, to: 1. Allocate a slot in the process table for the new process. 2. Assign a unique process ID to the child process. 3. Copy of process image of the parent, with the exception of any shared memory.
  55. Process Creation cont… 4. Increment the counters for any files owned by the parent, to reflect that an additional process now also owns those files. 5. Assign the child process to the Ready to Run state. 6. Returns the ID number of the child to the parent process, and a 0 value to the child process.
  56. After Creation • After creating the process the Kernel can do one of the following, as part of the dispatcher routine: – Stay in the parent process. – Transfer control to the child process – Transfer control to another process.

Notas do Editor

  1. {"49":"4. Select another process for execution; \n5. Update the process control block of the process selected. This includes changing the state of this process to Running.\n6. Update memory management data structures. This may be required, depending on how address translation is managed;\n7. Restore the context of the processor to that which existed at the time the selected process was last switched out of the Running state, by loading in the previous values of the program counter and other registers.\n","38":"Processor state information consists of the contents of processor registers. \nWhile a process is running the information is in the registers. \nWhen a process is interrupted, all of this register information must be saved so that it can be restored when the process resumes execution. Nature and number of processes vary by processor design\nTypically, the register set will include user-visible registers, control and status registers, and stack pointers. \n","27":"The comments are summarized due to space on slide\n","16":"Emphasize that you are introducing a Simple model and that this will be expanded.\nThe operating system’s principal responsibility is controlling the execution of processes;\nthis includes determining the interleaving pattern for execution and allocating resources to processes. \nThe first step in designing an OS to control processes is to describe the behaviour that we would like the processes to exhibit. In the most simple model, a process is either running, or it is not.\n","44":"The less-privileged mode is often referred to as the user mode, because user programs typically would execute in this mode. \nMention that System Mode is also known as\nControl Mode\nKernel Mode\nProtected Mode\nCertain instructions can only be executed in the more-privileged mode.\nIncluding reading or altering a control register, such as the program status word; \nprimitive I/O instructions; \nInstructions that relate to memory management. \nIn addition, certain regions of memory can only be accessed in the more-privileged mode. \nTable 3.7 lists the functions typically found in the kernel of an OS.\nQuestions: How does the processor know in which mode it is to be executing? And how does it change\nAnswer: \nTypically a flag (single bit) in the program status word (PSW). This bit is changed in response to certain events. \nTypically, when a user makes a call to an operating system service or when an interrupt triggers execution of an operating system routine, the mode is set to the kernel mode and, upon return from the service to the user process, the mode is set to user mode. \n","33":"I/O tables are used by the OS to manage the I/O devices and channels of the computer system.\nAt any given time, an I/O device may be available or assigned to a particular process. \nIf an I/O operation is in progress, the OS needs to know the status of the I/O operation and the location in main memory being used as the\nsource or destination of the I/O transfer. \n","22":"In the simplest solution, this model would require an additional queue for the blocked processes. \nBut when an event occurs the dispatcher would have to cycle through the entire queue to see which process is waiting for the event.\nThis can cause huge overhead when their may be 100’s or 1000’s of processes\n","39":"All processor designs include a register or set of registers, often known as the program status word (PSW), that contains status information.\nThe PSW typically contain condition codes plus other status information. \nA good example of a processor status word is that on Pentium processors, referred to as the EFLAGS register \nThis structure is used by any OS (including UNIX and Windows) running on a Pentium processor.\n","28":"Progress indicator\n","17":"Animated slide The animation only shows one process moving.\nThere needs to be some structure so that the OS can keep track of the processes. This could be a simple queue which is managed by the dispatcher routine of the OS.\n","56":"When the kernel has completed these functions it can do one of the following, as part of\nthe dispatcher routine:\n• Stay in the parent process. Control returns to user mode at the point of the fork call of the parent.\n• Transfer control to the child process. The child process begins executing at the same point in the code as the parent, namely at the return from the fork call.\n• Transfer control to another process. Both parent and child are left in the Ready to Run state.\n","34":"The OS may also maintain file tables.\nMuch, if not all, of this information may be maintained and used by a file management system, in which case the OS has little or no knowledge of files.\nIn other operating systems, much of the detail of file management is managed by the OS itself.\n","23":"More efficient to have a separate ‘blocked’ queue for each type of event.\n","1":"These slides are intended to help a teacher develop a presentation. This PowerPoint covers the entire chapter and includes too many slides for a single delivery. Professors are encouraged to adapt this presentation in ways which are best suited for their students and environment.\n","51":"A total of nine process states are recognized by the UNIX SVR4 operating system;\nThis figure is similar to Figure 3.9b, with the two UNIX sleeping states corresponding to the two blocked states. \nPoint out that:\nUNIX employs two Running states to indicate whether the process is executing in user mode or kernel mode.\nTwo states are essentially the same: (Ready to Run, in Memory) and (Pre-empted) as indicated by the dotted line. The distinction is made to emphasize the way in which the pre-empted state is entered. When a process is running in kernel mode (as a result of a supervisor call, clock interrupt, or I/O interrupt), there will come a time when the kernel has completed its work and is ready to return control to the user program. At this point, the kernel may decide to pre-empt the current process in favour of one that is ready and of higher priority. In that case, the current process moves to the pre-empted state. However, for purposes of dispatching, those processes in the pre-empted state and those in the Ready to Run, in Memory state form one queue.\n","40":"This is the additional information needed by the OS to control and coordinate the various active processes.\nThe last part of Table 3.5 indicates the scope of this information. \nAs we examine the details of operating system functionality in succeeding chapters, the need for the various items on this list should become clear.\n","29":"The OS controls events within the computer system. It schedules and dispatches processes for execution by the processor, allocates resources to processes, and responds\nto requests by user processes for basic services.\nFundamentally, we can think of the OS as that entity that manages the use of system resources by processes.\nIn this slide –\nThere are a number of processes (P1, . . ., Pn,) that have been created and exist in virtual memory. \nEach process, during the course of its execution, needs access to certain system resources, including the processor, I/O devices, and main memory.\nIn the figure, process P1 is running; at least part of the process is in main memory, and it has control of two I/O devices. \nProcess P2 is also in main memory but is blocked waiting for an I/O device allocated to P1.\nProcess Pn has been swapped out and is therefore suspended.\n","18":"There are many reasons why a process may be created or terminated. \n","35":"Finally, the OS must maintain process tables to manage processes. \nThe remainder of this section is devoted to an examination of the required process tables.\nNote: Although Figure 3.11 (earlier slide ) shows four distinct sets of tables, it should be clear that these tables must be linked or cross-referenced in some fashion. \nMemory, I/O, and files are managed on behalf of processes, so there must be some reference to these resources, directly or indirectly, in the process tables. \nThe files referred to in the file tables are accessible via an I/O device and will, at some times, be in main or virtual memory.\nThe tables themselves must be accessible by the OS and therefore are subject to memory management.\n","24":"Mention that the aim is to fully utilize the processor.\n","13":"Animated slide\nWipes down to give impression of process progression\n","2":"Note: In this chapter, reference is occasionally made to virtual memory. Much of the time, we can ignore this concept in dealing with processes, but at certain\npoints in the discussion, virtual memory considerations are pertinent. Virtual memory is not discussed in detail until Chapter 8.\nRefer students to a brief overview which is provided in Chapter 2.\n","41":"Figure 3.13 suggests the structure of process images in virtual memory. \nEach process image consists of\na process control block, \na user stack, \nthe private address space of the process, and \nany other address space that the process shares with other processes. \nIn the figure, each process image appears as a contiguous range of addresses. In an actual implementation, this may not be the case; it will depend on the memory management scheme and the way in which control structures are organized by the OS.\nThe process control block may contain structuring information, including pointers that allow the linking of process control blocks.\nThus, the queues that were described in the preceding section could be implemented as linked lists of process control blocks. \n","19":"Typically, the “related” processes need to communicate and cooperate with each other. Achieving this cooperation is a difficult task for the programmer; discussed further in Chapter 5.\n","47":"A process switch may occur any time that the OS has gained control from the currently running process. \nTable 3.8 suggests the possible events that may give control to the OS.\nTwo kinds of system interrupts, \none is simply called an interrupt, \nand the other called a trap.\n“interrupts” are due to some sort of event that is external to and independent of the currently running process, such as the completion of an I/O operation. \nWith an ordinary interrupt, control is first transferred to an interrupt handler, which does some basic housekeeping and then branches to an OS routine that is concerned with\nthe particular type of interrupt that has occurred.\n“Traps” relate to an error or exception condition generated within the currently running process, such as an illegal file access attempt.\nWith traps, the OS determines if the error or exception condition is fatal. \nIf so, then the currently running process is moved to the Exit state and a process switch occurs. \nIf not, then the action of the OS will depend on the nature of the error and the design of the OS.\nIt may attempt some recovery procedure or simply notify the user.\nIt may do a process switch or resume the currently running process.\nFinally, the OS may be activated by a supervisor call from the program being executed. \nFor example, a user process is running and an instruction is executed that requests an I/O operation, such as a file open.\nThis call results in a transfer to a routine that is part of the operating system code. The use of a system call may place the user process in the Blocked state.\n","36":"A sophisticated multiprogramming system requires a great deal of information about each process. \nDifferent systems will organize this information in different ways\nFor now, let us simply explore the type of information that might be of use to an OS without considering in any detail how that information is organized.\nTable 3.5 in the book (not in this slide set) lists the typical categories of information required by the OS for each process. \nWe can group the process control block information into three general categories:\n• Process identification\n• Processor state information\n• Process control information\n","25":"Again, the simple solution is to add a single state – but this only allows processes which are blocked to be swapped out.\n","14":"Animated slide \nExplain the scenario then click for the animation\nThe shaded areas represent code executed by the dispatcher. \nThe same sequence of instructions is executed by the dispatcher in each instance because the same functionality of the dispatcher is being executed.\nWe assume that the OS only allows a process to continue execution for a maximum of six instruction cycles, after which it is interrupted; this prevents any single process from monopolizing processor time. \nAnimate here\nThe first six instructions of process A are executed, followed by a time-out and the execution of some code in the dispatcher, which executes six instructions before turning control to process B2. \nAfter four instructions are executed, process B requests an I/O action for which it must wait. Therefore, the processor stops executing process B and moves on, via the dispatcher, to process C. \nAfter a time-out, the processor moves back to process A. When this process times out, process B is still waiting for the\nI/O operation to complete, so the dispatcher moves on to process C again.\n","3":"Explain that:\non a multiprogramming uniprocessor, the execution of multiple processes can be interleaved in time. \non a multiprocessor, not only may process execution be interleaved, but also multiple processes can execute simultaneously. \nExplain that process management is compounded by the introduction of the concept of thread. In a multithreaded system, \nthe process retains the attributes of resource ownership, \nThe thread retains the attributes of multiple, concurrent execution streams running within a process.\n","42":"The process control block is the most important data structure in an OS.\nEach process control block contains all of the information about a process that is needed by the OS. \nThe blocks are read and/or modified by virtually every module in the OS, including those involved with scheduling, resource allocation, interrupt processing, and performance monitoring and analysis.\nOne can say that the set of process control blocks defines the state of the OS.\nImportant design issue. \nA number of routines within the OS will need access to information in process control blocks.\nThe difficulty is not access but rather protection. \nTwo problems present themselves:\nA bug in a single routine, such as an interrupt handler, could damage process control blocks, which could destroy the system’s ability to manage the affected processes.\nA design change in the structure or semantics of the process control block could affect a number of modules in the OS.\n","31":"A general idea of the scope of the tables is in Figure 3.11, which shows four different types of tables maintained by the OS: \nmemory, \nI/O, \nfile, \nprocess.\nAlthough the details will differ from one OS to another, fundamentally, all operating systems maintain information in these four categories.\nThe next few slides mention details of these four tables.\nYou may prefer to stick with this diagram and discuss each from here\n","9":"Mention that this list is not necessarily complete, and may include optional elements (e.g. not all OS’s may need a process to have accounting information)\n","48":"If the currently running process is to be moved to another state (Ready, Blocked, etc.), then the OS must make substantial changes in its environment. \nThe steps involved in a full process switch are as follows:\n1. Save the context of the processor, including program counter and other registers.\n2. Update the process control block of the process that is currently in the Running state. \nThis includes changing the state of the process to one of the other states (Ready; Blocked; Ready/Suspend; or Exit). Other relevant fields must also be updated, including the reason for leaving the Running state and accounting information.\n3. Move the process control block of this process to the appropriate queue (Ready;Blocked on Eventi; Ready/Suspend).\nMore next slide\n","37":"In virtually all operating systems, each process is assigned a unique numeric identifier, \nwhich may simply be an index into the primary process table (see Figure 3.11); \notherwise there must be a mapping that allows the OS to locate the appropriate tables based on the process identifier. \nThis identifier is useful in several ways. \nMany of the other tables controlled by the OS may use process identifiers to cross-reference process tables. \nFor example, \nThe memory tables may be organized so as to provide a map of main memory with an indication of which process is assigned to each region. \nSimilar references will appear in I/O and file tables.\nWhen processes communicate with one another, the process identifier informs the OS of the destination of a particular communication.\nWhen processes are allowed to create other processes, identifiers indicate the parent and descendents of each process.\nIn addition to these process identifiers, a process may be assigned a user identifier that indicates the user responsible for the job.\n","26":"Two suspend states allow all processes which are not actually running to be swapped.\nRun through the four states:\nReady: The process is in main memory and available for execution.\n• Blocked: The process is in main memory and awaiting an event.\n• Blocked/Suspend: The process is in secondary memory and awaiting an event.\n• Ready/Suspend: The process is in secondary memory but is available for execution as soon as it is loaded into main memory.\nIt would be useful to also summarise the main transitions (abridged)\nBlocked  Blocked/Suspend: If there are no ready processes, then at least one blocked process is swapped out to make room for another process that is not blocked. This transition can be made even if there are ready processes available, if the OS determines that the currently running process or a ready process that it would like to dispatch requires more main memory to maintain adequate performance.\nBlocked/Suspend  Ready/Suspend: A process in the Blocked/Suspend state is moved to the Ready/Suspend state when the event for which it has been waiting occurs. \nReady/Suspend S  Ready: When there are no ready processes in main memory, or if a suspended process has a higher priority, the OS will need to bring one in to continue execution. \nReady  Ready/Suspend: Normally, the OS would prefer to suspend a blocked process rather than a ready one, because the ready process can now be executed, whereas the blocked process is taking up main memory space and cannot be executed. However, it may be necessary to suspend a ready process if that is the only way to free up a sufficiently large block of main memory.\nSeveral other transitions that are worth considering are the following:\nNew  Ready/Suspend and New Ready: When a new process is created, it can either be added to the Ready queue or the Ready/Suspend queue. In either case, the OS must create a process control block and allocate an address space to the process. It might be preferable for the OS to perform these housekeeping duties at an early time, so that it can maintain a large pool of processes that are not blocked. With this strategy, there would often be insufficient room in main memory for a new process; hence the use of the (New  Ready/Suspend) transition. \nBlocked/Suspend  Blocked: Inclusion of this transition may seem to be poor design. After all, if a process is not ready to execute and is not already in main memory, what is the point of bringing it in? But consider the following scenario:\nA process terminates, freeing up some main memory.\nThere is a process in the (Blocked/Suspend) queue with a higher priority than any of the processes in the (Ready/Suspend) queue and \nthe OS has reason to believe that the blocking event for that process will occur soon. \nUnder these circumstances, it would seem reasonable to bring a blocked process into main memory in preference to a ready process.\nRunning  Ready/Suspend: Normally, a running process is moved to the Ready state when its time allocation expires. If, however, the OS is pre-empting the process because a higher-priority process on the Blocked/Suspend queue has just become unblocked, the OS could move the running process directly to the (Ready/Suspend) queue and free some main memory.\nAny State  Exit: Typically, a process terminates while it is running, either because it has completed or because of some fatal fault condition. However, in some operating systems, a process may be terminated by the process that created it or when the parent process is itself terminated. If this is allowed, then a process in any state can be moved to the Exit state.\n","15":"Progress indicator\n","4":"Recapping chapters 1 & 2\n","43":"Progress indicator\n","32":"Memory tables are used to keep track of both main (real) and secondary (virtual) memory. \nSome of main memory is reserved for use by the OS; the remainder is available for use by processes. \nProcesses are maintained on secondary memory using some sort of virtual memory or simple swapping mechanism.\n","21":"If all processes were always ready to execute, then the simple FIFO queuing model would suffice.\nHowever, even with simple examples, this implementation is inadequate:\nsome processes in the Not Running state are ready to execute,\nwhile others are blocked, waiting for an I/O operation to complete.\nIn a two state model, the dispatcher would have to scan the list looking for the process that is not blocked and that has been in the queue the longest.\nBut we could split the Not Running state into two states: \nReady and \nBlocked. \nFor good measure, we have added two additional states that will prove useful (new and exit)\nSuggestion: \nMention that “Wait” and “Blocked” have the same meaning here.\nTalk through the state transitions.\n","10":"Emphasise that the Process Control Block contains sufficient information so that it is possible to interrupt a running process and later resume execution as if the interruption had not occurred.\n"}