1. © Janice Regan, CMPT 300, May 2007 0 CMPT 300 Introduction to Operating Systems Operating Systems Processes and Threads

2. © Janice Regan, CMPT 300, May 2007 1 What is a process?  A process (active entity) is a program (static entity) in execution, and includes  An address space, an area in memory (memory location x to y) containing List of instructions Any required data The stack for the program  Registers  Other information (includes resources used, status of I/O )

3. © Janice Regan, CMPT 300, May 2007 2 Multiprocessing shares memory  When multiple processes are sharing the CPU the memory is shared between them  Each process can only access it’s own area of memory (program image, stack, …)  Pointers (stored in registers) give the base address and the length or end address. (shown here in # of words) Process C Process A Process B Dispatcher 250 10000 7000 5000 4000 1000

4. © Janice Regan, CMPT 300, May 2007 3 Processes/Threads  A process groups all resources needed to execute a program  Our OS switches between processes and otherwise manages processes, this incurs a significant overhead for each process  Processes are useful for encapsulation and security.  They cannot access each others memory space  The resources they use are protected from other processes  This can be useful when processes are competing for resources (different owners who want optimal turnaround)  However, sometimes we want programs to be able to interact and cooperate and even share memory space when they run, (controlled by the same user, cooperating with each other). The process model does not allow this.

5. Path of Execution  A path of execution can be thought of as a list of instructions in order they are actually executed when a particular process executes.  Two different processes running the same program can have different threads of execution  A thread follows a particular path of execution through a program © Janice Regan, CMPT 300, May 2007 4

6. 5 What is a thread?  A “lightweight process”  Each thread has its own program image  Program counter, registers  Stack (path of execution), automatic data  State  Each thread in a particular process shares  Program text, Global variables  Files and other communication connections  State (different from process state)

7. What is shared 6 REGISTERS STACK Includes Automatic variables User address space Code Global variables Heap Static variables © Janice Regan, CMPT 300, May 2007 Process control block Process Thread 1Thread 2 Thread 3 Thread ocntrol block Thread control block REGSITERS STACK Includes Automatic variables REGISTERS STACK Includes Automatic variables Shared

8. © Janice Regan, CMPT 300, May 2007 7 Resource ownership  Separate the two main characteristics of a process, Resource ownership/management and Scheduling/execution.  Resource ownership: Address space holding a process image (program, data, state stored in process control block), main memory, connections to I/O devices, other hardware devices and other processes (also stored in process control block)  Owned by a process  Shared by a thread

9. © Janice Regan, CMPT 300, May 2007 8 Scheduling, execution  Separate the two main characteristics of a process, Resource ownership/management and Scheduling/execution.  Scheduling/dispatching/execution  Program counter, registers, stack, locally declared (automatic variables) variables owned by each thread within a process  Follows an execution path through the program image (trace through the code)  Execution path is unique to each process, and to each thread within a process

10. © Janice Regan, CMPT 300, May 2007 9 Multithreading: advantages Multithreading: The ability of the operating system to support more than one concurrent thread of execution within any given process  Increases efficiency over using multiple processes because  Fewer process context switches (using shared image)  Less thread context to save (program counter, local thread specific variables, thread state)  Takes less time to create/terminate a thread than a process (less to copy)

11. © Janice Regan, CMPT 300, May 2007 10 Multithreading: disadvantages  Sharing increases possibility of synchronization problems  Each thread can modify all variables in the memory image (but cannot control order modifications are done)  All files and other communication connections are shared. Reading in one thread, moves read pointer  Suspending a process means suspending several threads to allow the image to be swapped  If you fork a multithreaded process, what happens?

12. © Janice Regan, CMPT 300, May 2007 11 When threads are useful  Multiprocessor systems (simultaneous execution of different threads on multiple processors)  Foreground (display and input) and background work (using a word processor, spreadsheet …)  Asynchronous processing (timed save in a word processor, I/0 processing in background …)  Efficiency advantages of multiprocessing within on process (one thread blocked, run another)  Modularization: different threads in the process taking care of different modularized tasks (I/0 from/to various sources/destinations …)  Good examples in your text

13. © Janice Regan, CMPT 300, May 2007 12 Implementing threads  Two main approaches to implementation  User level threads (POSIX Pthreads) Thread management is the responsibility of the user and occurs completely in user mode. Thread scheduling is user controlled, you can choose the best way to schedule your own threads Blocking system calls or page faults block all threads (not just one) must wrapper the call so thread is not blocked if device is busy Cannot take advantages of multiprocessors  Kernel level threads (Windows, newer Linux releases) All thread management is done by the kernel Requires mode switch to kernel to move between threads API to the kernel thread facility provides users access through system calls O/S dependent

14. Process and Thread States  We have discussed the possible states of a process (running, blocked, ready, … ).  Each thread in a process can have its own state. The states have the same names but we must remember that they refer to only one thread  Consider a process that is in the running state. If that process has multiple threads only one of its threads will be in the running state, the others will be in blocked state or in ready state © Janice Regan, CMPT 300, May 2007 13

15. User Level Threads © Janice Regan, CMPT 300, May 2007 14 User Space Kernel Space T1 P T2T3 P Thread Library

16. © Janice Regan, CMPT 300, May 2007 15 User level threads  The application does the thread management in user space with the help of a thread library  The kernel is not aware that threads are being used  An application begins as a process with a single thread.  The application keeps its own thread table to keep track of all threads it has created using the library routine thread_create()  The application must use thread_yield() to ask the scheduler (library) to switch to the another thread  No context switch or interrupt are needed (fast)  Cannot let the OS scheduler manage sharing between threads because the OS (kernel level) does not know threads exist

17. Some possible situations  The process is in running state, one thread yields to another thread in the same process  The process is in ready state, one of the process’s threads is in running state  The process is blocked in blocked state, one of the process’s threads is in running state. © Janice Regan, CMPT 300, May 2007 16

18. user –level thread multiprocessing  The threaded application starts as a process containing a single thread. The process is in the running state.  The application uses the user-level thread library to create additional threads  When thread A begins to run it will enter the running state. Thread A will continue until it calls thread_yield()  When thread_yield() executes it will place Thread A into the ready state, place thread B into the running state (formerly in waiting state) and start running thread B  The process is still in the running state © Janice Regan, CMPT 300, May 2007 17

19. User level threads: timesharing  The threaded application starts as a process containing a single thread. The process is in the running state.  The application uses the user-level thread library to create additional threads  Thread A (in process 1) has been executing for one process timesharing quantum and the timer interrupt has transferred control to the kernel.  The kernel does not know about the threads, it saves the context of process 1 and moves process 1 to ready state, and starts executing process 2  Thread A is still in running state even though process 1 is in ready state © Janice Regan, CMPT 300, May 2007 18

20. User level threads: blocking  The threaded application starts as a process containing a single thread. The process is in the running state.  The application uses the user-level thread library to create additional threads  When thread A begins to run it will enter the running state. Thread A makes an I/O system call.  Control is transferred to the kernel which blocks the process  Remember the kernel does not know about the threads  Thread A is still in state running, even though the process is in state blocked  It is not possible to run any part (any thread) of the blocked process © Janice Regan, CMPT 300, May 2007 19

21. User level threads: advantages  The process does not have to switch to kernel mode to do thread management  Scheduling is implemented by the application (using the thread library) so scheduling can be application specific  User level thread libraries can be portable (can run on more than one OS) © Janice Regan, CMPT 300, May 2007 20

22. User level: disadvantages  When one thread makes a system call which causes it to be blocked, the entire process is blocked (use jacketing to mitigate)  A multithreaded application does not benefit from multiprocessing or time sharing. (these occur on a per process basis)  When a multithreaded process calls fork() should some or all threads be duplicated?  Not a simple question © Janice Regan, CMPT 300, May 2007 21

23. Jacketing  Convert blocking system calls to non-blocking system calls  Write a jacket routine that checks to see if the blocking devise is presently busy  If the devise is busy and would block control is passed to a different thread. Otherwise execute the request  When control returns from the other thread repeat the previous step  Must have a system call to check if a blocking device is busy (select) © Janice Regan, CMPT 300, May 2007 22

24. Kernel-Level Threads © Janice Regan, CMPT 300, May 2007 23 User Space Kernel Space T1 P T2T3 P

25. Kernel-level threads  Kernel maintains process control blocks describing each process and thread control blocks describing each thread  Threads from the same process can be scheduled independently. Scheduling can be done for threads rather than just for processes.  If one thread is blocked, the other threads in the process are not blocked  Switching threads requires a system call and is therefore less efficient © Janice Regan, CMPT 300, May 2007 24

26. 25 Hello world for threads  Process to be executed by each thread that is created. When function returns thread terminates void *hola(void * arg) { int myid=*(int *) arg; printf("Hello, world, I'm %d\n",myid); return arg; } Author: Mark Hays http://math.arizona.edu/~swig/documentation/pthreads/

27. Creating Threads pthread_t threads[NTHREADS]; /* holds thread info */ int ids[NTHREADS]; /* holds thread args */ for (worker=0; worker<NTHREADS; worker++) { ids[worker]=worker; if ( errcode = pthread_create (&threads[worker], NULL, /* default thread attributes */ hola, /* start routine */ &ids[worker])) { errexit(errcode,"pthread_create"); } 26 Author: Mark Hays http://math.arizona.edu/~swig/documentation/pthreads/

28. Waiting for threads to terminate for (worker=0; worker<NTHREADS; worker++) { /* wait for thread to terminate */ if (errcode=pthread_join(threads[worker],(void *) &status)) { errexit(errcode,"pthread_join"); } /* check thread's exit status and release its resources */ if (*status != worker) { fprintf(stderr,"thread %d terminated abnormally\n",worker); exit(1); } 27 Author: Mark Hays http://math.arizona.edu/~swig/documentation/pthreads/