1. Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, Chapter 3: Process-Concept

2. 3.2 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Chapter 3: Process-Concept Process Concept Process Scheduling Operations on Processes Interprocess Communication Examples of IPC Systems Communication in Client-Server Systems

3. 3.3 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Objectives To introduce the notion of a process -- a program in execution, which forms the basis of all computation To describe the various features of processes, including scheduling, creation and termination, and communication To describe communication in client-server systems

4. 3.4 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Process Creation Parent process create children processes, which, in turn create other processes, forming a tree of processes Generally, process identified and managed via a process identifier (pid) Resource sharing Parent and children share all resources Children share subset of parent’s resources (preventing them from overloading the system by creating many processes. Parent and child share no resources (direct access from OS) Execution Parent and children execute concurrently Parent waits until children terminate

5. 3.5 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Process Creation (Cont) Address space with UNIX example to illustrate the differences Child duplicate of parent (has the same program and data as parent)  Each process is identified by integer number “pid”  fork() system call creates new process  takes copy of address space of parent process. This allows easily communication between them. Child has a program loaded into it  Exec() system call used after a fork() to replace the process’ memory space with a new program  The exec() sys. Call loads a binary file  memory  Two processes can communicate and continue execution separately.  Parent can create new processes or wait (wait () system call)

6. 3.6 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Process Creation

7. 3.7 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition C Program Forking Separate Process int main() { pid_t pid; /* fork another process */ pid = fork(); if (pid < 0) { /* error occurred */ fprintf(stderr, "Fork Failed"); exit(-1); } else if (pid == 0) { /* child process */ execlp("/bin/ls", "ls", NULL); } else { /* parent process */ /* parent will wait for the child to complete */ wait (NULL); printf ("Child Complete"); exit(0); }

8. 3.8 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition A tree of processes on a typical Solaris

9. 3.9 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Process Termination Process executes last statement and asks the operating system to delete it (exit () Sys. Call) Output data passed from child to parent (via wait() Sys. Call) Process’ resources are de-allocated by operating system Parent may terminate execution of children processes (abort) when: Child has exceeded allocated resources The task assigned to child is no longer required If parent is exiting  Some operating system do not allow child to continue if its parent terminates – All children terminated - cascading termination

10. 3.10 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Interprocess Communication Processes within a system can be independent or cooperating Cooperating process can affect or be affected by other processes, including sharing data Reasons for cooperating processes: Information sharing (other P want to share information) Computation speedup (we break task into sub-tasks and executed in parallel) Modularity (divide the system into separate processes or threads) Convenience (allow user to work in many tasks) Cooperating processes need interprocess communication (IPC) mechanism: there are two models of IPC (1) Shared memory (2) Message passing

11. 3.11 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Communications Models Communications models: (a) Message Passing (b) Shared Memory

12. 3.12 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Cooperating Processes Independent process cannot affect or be affected by the execution of another process Cooperating process can affect or be affected by the execution of another process Advantages of process cooperation Information sharing Computation speed-up Modularity Convenience

13. 3.13 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Shared-Memory Systems Establish a region of a shared memory Recall, OS prevents other process from accessing other process’s memory. Two or more processes must agree to remove this restriction. Processes can exchange information by reading/writing data in the shared areas. The form of the data and the location are determined by the processes not the OS’s control. Processes are responsible not to write at the same location simultaneously.

14. 3.14 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Shared-Memory Systems To illustrate the concept of cooperating process, we consider producer- consumer problem Example : A producer process produces information that consumed by a consumer process. Ex1: a compiler may produce assembly code, which is consumed by an assembler. The assembler, in turn, may produce object modules, which are consumed by the loader. One solution to producer-consumer problem is to use shared memory. Provide buffer that can be filled by producer and emptied by the consumer. The buffer resides in memory that is shared by producer and consumer.

15. 3.15 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Producer-Consumer Problem Two types of buffers can be used in the paradigm of cooperating process: unbounded-buffer places no practical limit on the size of the buffer: producer can always produce new items, while consumer has to wait for new items. bounded-buffer assumes that there is a fixed buffer size: producer must to wait if the buffer is full, and consumer must wait if the buffer is empty.

16. 3.16 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Bounded-Buffer – Shared-Memory Solution The following code is implemented to illustrate the bounded-buffer-shared memory model. The variables reside in shared memory by the producer and consumer. The shared buffer is implemented as a circular array with two logical pointers: in: points to the next free position in the buffer out: points to the first full position in the buffer. The buffer is empty when in==out. The buffer is full when ((in+1)%buffer_size) ==out. The producer process uses nextProduced variable for storing new item. The consumer process uses nextConsumed variable in which the item to be consumed is stored. The scheme allows at most Buffer_size-1 items in the buffer at the same time

17. 3.17 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition

18. 3.18 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Bounded-Buffer – Shared-Memory Solution Shared data #define BUFFER_SIZE 10 typedef struct {... } item; item buffer[BUFFER_SIZE]; int in = 0; points to the next free position int out = 0; points to the next full position Solution is correct, but can only use BUFFER_SIZE-1 elements

19. 3.19 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Bounded-Buffer – Producer while (true) { /* Produce an item and store it in nextProduced */ while (((in = (in + 1) % BUFFER SIZE count) == out) ; /* do nothing -- no free buffers */ buffer[in] = nextProduced; in = (in + 1) % BUFFER SIZE; }

20. 3.20 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Bounded Buffer – Consumer while (true) { /* Wait for an item to become available */ while (in == out) ; // do nothing -- nothing to consume /* remove an item from the buffer Get the next available item */ next Consumed= buffer[out]; out = (out + 1) % BUFFER SIZE; /* Consume the item in nextConsumed */ return item; }

21. 3.21 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Interprocess Communication – Message Passing Mechanism for processes to communicate and to synchronize their actions Message system – processes communicate with each other without resorting to shared variables (shared memory) IPC- message passing facility provides two operations: send(message) – message size fixed or variable receive(message) If P and Q wish to communicate, they need to: establish a communication link between them exchange messages via send/receive operations Implementation of communication link physical (e.g., shared memory, hardware bus) logical (e.g., logical properties)

22. 3.22 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Interprocess Communication – Message Passing Several methods for logically implementing a link and the send() / received() operations: Direct or indirect communication Synchronous or asynchronous communication Automatic or explicit buffering

23. 3.23 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Implementation Questions How are links established? Can a link be associated with more than two processes? How many links can there be between every pair of communicating processes? What is the capacity of a link? Is the size of a message that the link can accommodate fixed or variable? Is a link unidirectional or bi-directional?

24. 3.24 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Naming Processes use a way to communicate which can be direct or indirect Communication. (A) Direct communication: Use send() and receive() primitives. Processes must name each other explicitly:  send (P, message) – send a message to process P  receive(Q, message) – receive a message from process Q Properties of communication link  Links are established automatically  A link is associated with exactly one pair of communicating processes  Between each pair there exists exactly one link  The link may be unidirectional, but is usually bi-directional

25. 3.25 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Naming The previous way in communication represent a symmetry in addressing, both sender and receiver process must name each other. The asymmetry in addressing only the sender names the recipient: send (P, message) – send a message to process P receive(id, message) – receive a message from any process, where the variable id is set to the name of the process with which communication has taken place. This technique is hard to implement, b/c need to examine all old identifiers and modified to new ones.

26. 3.26 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Naming (B) Indirect Communication: Messages are direct and received from mailboxes (also referred to as ports) Each mailbox has a unique id Processes can communicate only if they share a mailbox Properties of communication link Link established only if processes share a common mailbox A link may be associated with many processes Each pair of processes may share several communication links Link may be unidirectional or bi-directional

27. 3.27 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Naming (B) Indirect Communication: Operations create a new mailbox send and receive messages through mailbox destroy a mailbox Primitives are defined as: send(A, message) – send a message to mailbox A receive(A, message) – receive a message from mailbox A

28. 3.28 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Naming (B) Indirect Communication: How about Mailbox sharing? P 1, P 2, and P 3 share mailbox A P 1, sends; P 2 and P 3 receive Who gets the message? Solutions Allow a link to be associated with at most two processes Allow only one process at a time to execute a receive operation Allow the system to select arbitrarily the receiver. Sender is notified who the receiver was.

29. 3.29 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Naming (B) Indirect Communication: Mailbox owned by: Process: mailbox is part of the address space of the process.  Distinguish between the owner (which can only receive a message through this mailbox) and the user (which can send a message to this mailbox).  When a process that owns a mailbox terminates, the mailbox disappears. O.S.: mailbox is independent from any other process.

30. 3.30 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition (2) Synchronization Communication between processes takes place through send(), receive(). Message passing may be either blocking or non-blocking Blocking is considered synchronous Blocking send: sender is blocked until the message is received by process or mailbox Blocking receive receiver is blocked until a message is available Non-blocking is considered asynchronous Non-blocking: sender process sends the message and continue its operation Non-blocking receiver process receives a valid message or null

31. 3.31 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition (3) Buffering Whether communication is direct or indirect, messages exchanged by communicating processes reside in a temporary queue. Such queue can be implemented in one of three ways 1.Zero capacity – 0 messages: queue cannot have any messages waiting in it. Sender must block until message is received. Sender must wait for receiver. 2.Bounded capacity – finite length of n messages Sender must wait if link full,. Sender must block until space is available in the queue. 3.Unbounded capacity – infinite length. Sender never waits

32. 3.32 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Communications in Client-Server Systems Sockets Remote Procedure Calls Remote Method Invocation (Java)

33. 3.33 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Sockets A socket is defined as an endpoint for communication Socket is identified by an IP address concatenated with a port number using client-server architecture. A pair of processes communicating over a network employ a pair of sockets. The socket 161.25.19.8:1625 refers to port 1625 on host 161.25.19.8 Communication consists between a pair of sockets

34. 3.34 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Socket Communication

35. 3.35 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Sockets In general: Server waits for incoming client requests by listing to a specific port. Once request is received, the server accepts a connection from the client socket to complete the connection. Servers implementing specific services (such as telnet, FTP, and HTTP) listen to well-known ports (telnet server listen to port 23, FTP:21, HTTP:80) all ports below 1024 are considered well-known, reserved for standard services.

36. 3.36 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Sockets Example: Suppose a client process initiates a request for a connection, a port will be assigned by host computer which will be greater than 1024. In more detials: a client on host X with IP 146.86.5.20 wants to establish a connection with web server listing to port 80 at address 161.25.19.8, host X may assigned port 1625. The connection consists of a pair of sockets: (146.86.5.20:1625) on host X and (161.25.19.8:80) on the web server.

37. 3.37 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Remote Procedure Calls Remote procedure call (RPC) abstracts procedure calls between processes on networked systems It is one of the most common forms of remote service RPC allows a client to invoke a procedure on a remote host as it was locally. Each message is addressed to an RPC daemon listening to a port on the remote system, each contains an identifier of the function to execute and parameters to pass to the that function. Function is then executed, output sent back to the requester in a separate message. EX. to provide a list of current users, a daemon support RPC for this will be attached to a port ex 3027. Any remote system can obtain the list, by sending an RPC message to port 3027 on the server, then the list will be in a reply message.

38. 3.38 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Remote Procedure Calls RPC allows a client to invoke a procedure on a remote host. RPC hides communication details by providing Stub on the client side. In the server side, there is a stub for each specific service. The client-side stub locates the port on the server and marshalls the parameters Marshalling the parameters includes packing parameters into a form that can be transmitted over a network. Then transmits a message to the server using message passing. The server-side stub receives this message, unpacks the marshalled parameters, and performs the procedure on the server

39. 3.39 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Remote Procedure Calls But how about data representation in different systems: To solve this problem: RPC system uses machine independent representation of data. One such representation is known external data representation XDR. On the client side: parameter marshalling involves converting the machine dependent data into XDR before they are sent to server. On the server side: XDR data are unmarshalled and converted to the machine dependent representation for the server.

40. 3.40 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Remote Procedure Calls Problems of fail communication or problems of networking services: To solve this there are two protocols: (1) At most once (2) Exactly once (1) At most once : Attach a timestamp to each message Server keeps a history of all the timestamps of messages. Incoming messages with a timestamp in the history is ignored. Client can send a message one or more times and be assumed that only executes once. (2) Exactly once: Server implement At most once protocol and send acknowledgment “ACK” to the client that RPC was received and executed Client resend each RPC call periodically until it receives the ACK for that call.

41. 3.41 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Remote Procedure Calls In standard (normal) procedure calls inside the system itself, binding usually takes place during link, load, or execution time, so that the procedure call’s name is replaced by memory address of the procedure call. The question is! How does a client know the port numbers in the server?: Two ways: (1) Fixed port number is predetermined in binding. At a compile time, an RPC call is associated with a fixed port number. Once the program is compiled, server cannot change it. 2) Dynamic port number:  Server provides a rendezvous (matchmaker) daemon on a fixed RPC port.  A client sends a request to the rendezvous daemon asking about the port number of the RPC it need to execute.  Port number is returned, and RPC call can be sent to this port.

42. 3.42 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Execution of RPC

43. 3.43 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Remote Method Invocation Remote Method Invocation (RMI) is a Java mechanism similar to RPCs RMI allows a Java program on one machine to invoke a method on a remote object, even in the same system. Stub is in the client server where is skeleton in the server side. rendezvous

44. 3.44 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Java virtual machine A Java virtual machine is a program which executes certain other programs, namely those containing Java bytecode instructions A JVM provides an environment in which Java bytecode can be executed.

45. 3.45 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Marshalling Parameters in RMI

46. Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, End of Chapter 3