Chapter Three -- Processes -- Lecture Notes

• 3.0 Chapter Objectives
  • learn what a process is
  • learn about OS services that support processes
  • describe communication of client & server processes
  
  
• 3.1 Process Concept
  • Basically a process (aka job or sequential process) is an executing program.
  • "Program" and "process" are very different ideas. A program is like a recipe. It's basically just a set of instructions written down somewhere. When a cook makes a dish using a recipe, the cook is like a process.
  • Two or more cooks can be in a kitchen making the same dish, using (sharing) the same recipe. While they cook, they are not usually executing the same steps at the same time (although they could be). Each cook has to keep his or her place in the recipe. Each cook needs to have his own quantities of ingredients, implements, pots and pans.
  • Like cooks and recipes, it's possible for many processes to execute the same program concurrently. Like sharing the same recipe, typically they can share the program code, but they each need to have certain resources that they use exclusively - for example separate program counters to keep their places in the program, and separate runtime stacks to implement their function calls.
  • It is very important to understand that only one process can run at a time on a CPU. If a computer has one CPU, and a user process is executing, then the OS is suspended - asleep.
  • The OS keeps track of each process by representing it with a data structure. Typically we refer to the "process control block" -- the PCB. This is a name that represent the sum total of all the per-process data of which the OS keeps track.
  • It is necessary for the OS to store the entire context of the process in the PCB - everything that would be required to resume the process if it were deleted from the system.
  • Some things in the PCB: the state (new, running, waiting, ready, terminated); program counter; CPU registers; scheduling information; memory-management information; accounting information; and I/O status information.
  • On some level an OS can be understood as a queuing system. Processes make requests for resources like CPU time or I/O, and the OS puts PCB's in queues to represent processes waiting for resources.
  
  
• 3.2 Process Scheduling
  
  
• 3.3 Operations on Processes
  • In many systems the main mechanism for process creation is the ability of a process to create child processes. In a unix system typically the booting system creates a few primordial processes, and all other processes are their descendants. In unix, all user processes are typically descendents of the "init" process.
  • Process creation is something like a function call. A process creates a child to perform some task. The parent process may pass parameters and/or resources to the child. Examples of resources are open files or memory allocations.
  • A parent process typically can decide to execute concurrently with a child process, or it may decide to suspend itself until the child process completes its work. It can do this via a system call (wait).
  • Typically a parent process "owns" its child processes. For example, the parent process is able to terminate the child process.
  
  
• 3.4 Interprocess Communication
  • The modern OS has to provide mechanisms for processes to cooperate.
  • Users want to share data.
  • Programmers want to write programs that implement cooperating processes because those programs are efficient, or perhaps easier to design and understand.
  • Cooperating processes need to communicate. The basic means of communication are shared memory and passing messages through the kernel via system calls.
  • With shared memory communication, the shared region is typically established with the help of the OS and thereafter the cooperating processes use it to communicate without any further involvement of the OS. Process X communicates by writing information in a shared variable, which is then read by process Y. Processes have to employ synchronization protocols, for example to assure that messages are not read before they are written and that two processes don't attempt to write to the same set of memory locations at the same time.
  • The sample producer-consumer code on pages 98-99 give an example of a protocol that allows two processes to make use of a shared array in a synchronized manner, so that there are no errors. The producer will not overwrite an item that has not yet been consumed. The consumer will not attempt to copy out an item until the producer has copied in a 'fresh' item. (The example code is perhaps deceptively simple-looking.)
  
  
• 3.5 Examples of IPC Systems
  • Posix Shared Memory
  • Mach
  • Windows XP
  
  
• 3.6 Communication in Client-Server Systems
  • Sockets
  • Remote Procedure Call (RPC)
    • RPC semantics allow a client to invoke a procedure on a remote host - in the same way it would call a procedure locally.
    • When the client calls a non-local procedure, it results in a call to the RPC system, which calls a special stub procedure on the client side. The RPC system passes the function parameters to the stub.
    • The stub contacts a port on a server, marshalls parameters, and sends them in a message to the server.
    • A stub on the server side receives the message, invokes the procedure on the server side, and returns any needed results back to the client stub.
    • The function call made by the client returns normally - just as if it was a call to a local procedure.
  • Remote Method Invocation (RMI)