Process Communication & Threads

1. Process Communication & Threads Prepared by : Mazhar javedAwan BSCS-III

2. Process Creation • Parent process create children processes, which, in turn create other processes, forming a tree of processes. • Resource sharing • Parent and children share all resources. • Children share a subset of parent’s resources. • Parent and child share no resources. • Execution • Parent and children execute concurrently. • Parent waits until children terminate. • Address space • Child duplicate of parent. • Child has a program loaded onto it. • UNIX examples • fork system call creates a new process • exec system call used after a fork to replace the process’ memory image with a new executable. By : Mazhar Javed Awan

3. Process Termination • Process executes the last statement and requests the operating system to terminate it (exit). • Output data from child to parent (via wait). • Process resources are deallocated by the operating system, to be recycled later. • Parent may terminate execution of children processes (abort). • Reasons for termination: • Child has exceeded allocated resources (main memory, execution time, etc.). • Parent needs to create another child but has reached its maximum children limit • Task performed by the child is no longer required. • Parent exits. • Operating system does not allow child to continue if its parent terminates. • Cascaded termination By : Mazhar Javed Awan

4. Process Management in UNIX/Linux Important process-related UNIX/Linux system calls • fork • wait • exec • exit

5. fork() • When the fork system call is executed, a new process is created which consists of a copy of the address space of the parent. • This mechanism allows the parent process to communicate easily with the child process. • The return code for fork is zero for the child process and the process identifier of child is returned to the parent process. • On success, both processes continue execution at the instruction after the fork call. • On failure, -1 is returned to the parent process and errno is set appropriately to indicate the reason of failure; no child is created

6. fork()—Sample Code main() { int pid; ... pid = fork(); if (pid == 0) { /* Code for child */ ... } else { /* Code for parent */ ... } ... }

7. Processes classification • 1.Independentprocess cannot affect or be affected by the execution of another process.they cannot share data with other. 2.Cooperatingprocess can affect or be affected by the execution of another process

8. Cooperating Processes • Advantages of process cooperation • Information sharing • Computation speed-up • Modularity • Convenience • Concurrent execution requires • process communication • process synchronization

9. Interprocess Communication (IPC) • Mechanism for processes to communicate and synchronize their actions. • Via shared memory • Via Messaging system - processes communicate without resorting to shared variables. • Messaging system and shared memory not mutually exclusive - • can be used simultaneously within a single OS or a single process. • IPC facility provides two operations. • send(message) - message size can be fixed or variable • receive(message)

10. Producer-Consumer Problem • Paradigm for cooperating processes; • producer process produces information that is consumed by a consumer process. • We need buffer of items that can be filled by producer and emptied by consumer. • Unbounded-buffer places no practical limit on the size of the buffer. Consumer may wait, producer never waits. • Bounded-buffer assumes that there is a fixed buffer size. Consumer waits for new item, producer waits if buffer is full. • Producer and Consumer must synchronize.

11. Producer-Consumer using IPC • Producer repeat … produce an item in nextp; … send(consumer, nextp); until false; • Consumer repeat receive(producer, nextc); … consume item from nextc; … until false;

12. Cooperating Processes via Message Passing • If processes P and Q wish to communicate, they need to: • establish a communication link between them • exchange messages via send/receive • Fixed vs. Variable size message • Fixed message size - straightforward physical implementation, programming task is difficult due to fragmentation • Variable message size - simpler programming, more complex physical implementation.

13. Implementation Questions • How are links established? • Can a link be associated with more than 2 processes? • How many links can there be between every pair of communicating processes? • What is the capacity of a link? • Fixed or variable size messages? • Unidirectional or bidirectional links? …….

14. Direct Communication • Sender and Receiver 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. • Exactly one link between each pair. • Link may be unidirectional, usually bidirectional.

15. Indirect Communication • Messages are directed to and received from mailboxes (also called ports) • Unique ID for every mailbox. • Processes can communicate only if they share a mailbox. Send(A, message) /* send message to mailbox A */ Receive(A, message) /* receive message from mailbox A */ • Properties of communication link • Link established only if processes share a common mailbox. • Link can be associated with many processes. • Pair of processes may share several communication links • Links may be unidirectional or bidirectional

16. Indirect communication Mailboxes • Operations • create a new mailbox • send/receive messages through mailbox • destroy a mailbox • Issue: Mailbox sharing • P1, P2 and P3 share mailbox A. • P1 sends message, P2 and P3 receive… who gets message?? • Possible Solutions • disallow links between more than 2 processes • allow only one process at a time to execute receive operation • allow system to arbitrarily select receiver and then notify sender.

17. Synchronization • Message passing may be either blocking or non-blocking. • Blocking is considered synchronous • Non-blocking is considered asynchronous • send and receive primitives may be either blocking or non-blocking.

18. Buffering • Queue of messages attached to the link; implemented in one of three ways. Zero capacity – No messages Sender must wait for receiver Bounded capacity – n messages Sender must wait if link full. Unbounded capacity – infinite length Sender never waits.

19. Threads • Processes do not share resources well • high context switching overhead • A thread (or lightweight process) • basic unit of CPU utilization; it consists of: • program counter, register set and stack space • A thread shares the following with peer threads: • code section, data section and OS resources (open files, signals) • Collectively called a task. • Heavyweight process is a task with one thread.

20. Single and Multithreaded Processes

21. Benefits • Responsiveness • Resource Sharing • Economy • Utilization of MP Architectures

22. Threads(Cont.) • In a multiple threaded task, while one server thread is blocked and waiting, a second thread in the same task can run. • Cooperation of multiple threads in the same job confers higher throughput and improved performance. • Applications that require sharing a common buffer (i.e. producer-consumer) benefit from thread utilization. • Threads provide a mechanism that allows sequential processes to make blocking system calls while also achieving parallelism. • Thread context switch still requires a register set switch, but no memory management related work!! • Thread states - • ready, blocked, running, terminated • Threads share CPU and only one thread can run at a time. • No protection among threads.

23. Threads (cont.) • Kernel-supported threads (Mach and OS/2) • User-level threads • Hybrid approach implements both user-level and kernel-supported threads (Solaris 2).

24. User Threads • Thread management done by user-level threads library • Supported above the kernel, via a set of library calls at the user level. • Threads do not need to call OS and cause interrupts to kernel - fast. • Disadv: If kernel is single threaded, system call from any thread can block the entire task. • Example thread libraries: • POSIX Pthreads • Win32 threads • Java threads

25. Kernel Threads • Supported by the Kernel • Examples • Windows XP/2000 • Solaris • Linux • Tru64 UNIX • Mac OS X • Mach, OS/2

26. Multithreading Models • Many-to-One • One-to-One • Many-to-Many

27. Many-to-One • Many user-level threads mapped to single kernel thread • Examples: • Solaris Green Threads • GNU Portable Threads

28. One-to-One • Each user-level thread maps to kernel thread • Examples • Windows NT/XP/2000 • Linux • Solaris 9 and later

29. Many-to-Many Model • Allows many user level threads to be mapped to many kernel threads • Allows the operating system to create a sufficient number of kernel threads • Solaris prior to version 9 • Windows NT/2000 with the ThreadFiber package