240 likes | 319 Views
operating systems. Threads. Motivation. Suppose you have an application that is blocking while waiting for some input to become available This is easy when there is only one source of input. What do you do if there are multiple sources of input?
E N D
operating systems Threads
Motivation Suppose you have an application that is blocking while waiting for some input to become available This is easy when there is only one source of input. What do you do if there are multiple sources of input? The problem is that you don’t know from which source the next input will come from. It’s completely asynchronous. This is common in client-server applications, where a server may be expecting input from multiple clients.
Solutions 1. Use a separate process to monitor each input source. Only works when the streams are independent of one another. 2. Use select or poll calls. The process is blocked, so no useful processing can go on 3. Use non-blocking I/O and Poll Works if the program has useful work it can do between checks to see if I/O is complete. 4. Use POSIX asynchronous I/O and signals Complex and difficult to implement correctly
Solutions 5. Use threads, assigning each thread an open file descriptor Extremely simple, since each thread only worries about one file descriptor. The logic in each thread is simple. The program can overlap processing and waiting for input in a transparent way.
Thread Solution Suppose that you have written a function, processfd, that handles the processing of an individual file descriptor. With a single thread of execution, the flow of control looks like calling program called function processfd( ) { }; Note: If this function blocks on I/O, the whole process is blocked! processfd( );
Thread Solution But using threads, the flow of control looks like this: creating program created thread processfd( ) { }; thread creation processfd( );
Threads operating systems A Thread, or thread of execution, is the sequence of instructions being executed. A process may have one or more threads. Each thread has its own * program counter * set of registers * execution stack But, all threads within a process share the same address space (global variables), the same files, the same signals, and the same child processes!
code pc data stack files code files pc stack stack pc data registers registers registers thread thread thread multiple thread process single thread process
operating systems Benefits of using threads Responsiveness: One thread can run while another is blocked * Resource sharing Economy: On a Solaris (SUN) O/S Thread creation is 30 times faster than process creation Context switching for a thread is 5 times faster than process context switching Exploitation of multi-processor architectures * Assuming that threads are implemented in the kernel
operating systems Implementing Threads There are two approaches to implementing threads, and the differences are quite controversial. Support for threads can be provided either at the user level or by the kernel. Virtually all contemporary operating systems support kernel threads.
Implementing Threads operating systems Implementing Threads in User Space -- many to One Model -- A run-time system provides the interface to manage threads Each process has it’s own thread table No trap to kernel space is needed, no context switch is needed process process user space threads threads run-time system run-time system thread table thread table kernel space process table
Implementing Threads operating systems Implementing Threads in User Space Problems: 1. A blocking system call issued in one thread will block all threads in the process. 2. If a page fault occurs in one thread, all threads are blocked while the system pages. 3. Once a thread starts running there is no way to interrupt it. It must give up the cpu voluntarily. process process user space threads threads run-time system run-time system thread table thread table kernel space process table
Implementing Threads operating systems Implementing Threads in the Kernel -- one to one model -- No run time system. Use kernel calls to manage threads Thread table is kept in the kernel Kernel schedules threads, no blocking issues But … thread system calls are much more expensive than using a run-time system. process process user space threads threads kernel space process table thread table
Implementing Threads operating systems There is a hybrid approach to thread support used by Linux. The kernel has a small set of re-usable threads that it manages. Threads in user space are mapped onto one of the available kernel threads. process process user space threads threads run-time system run-time system thread table thread table kernel space process table thread table
operating systems Thread Packages A thread package usually includes functions for creating threads, destroying threads, enforcement of mutual exclusion, and conditional waiting. A typical thread package also includes a run-time system to manage threads transparently to the user. When a thread is created, a data structure is allocated to hold the thread’s id, its stack, registers, and program counter. Thread packages may be implemented in user space, in the kernel, or both.
Thread Libraries There are three main thread libraries in use today * POSIX pthreads * win32 threads * Java threads
POSIX Thread Package pthread_cancel pthread_create pthread_detach pthread_equal pthread_exit pthread_kill pthread_join pthread_self terminate another thread create a thread set a thread to release resources test two thread ids for equality exit a thread send a signal to a thread wait for a thread find out your own thread ID
operating systems User Thread Packages pthread package mach c-threads Sun Solaris3 UI threads Kernel Threads Windows NT, XP OS-X Mach Threads
operating systems pthreads The solution to writing portable, multi-threaded applications is to use POSIX threads. POSIX threads work on Linux, FreeBSD, Solaris, AIX, and other *nix systems. OS/X uses pthreads. They are not shipped with Windows, but pthread packages for Windows are available from other vendors.
operating systems Posix Thread Suppport Prior to POSIX 1003.1c, there was no standard interface for threads. Each vendor, if they supported threads at all, had their own threads package. POSIX standardized threads in POSIX1003.1c, in June of 1995 * Posix Threads are implemented as kernel threads on OS X
operating systems Re-entrant Code When using threads, you must take care that any code you use is reentrant. Reentrant code can be called more than once, perhaps from different threads, without conflicts. Each copy of the code must have its own copy of any variables that it uses, so must not use global or static variables Be careful when using threads, because some system calls are not thread-safe.
Thread Issues When a thread issues a fork( ) system call, does the new process contain just one thread, or all of the threads of the original process?
Thread Issues When a signal occurs, should the signal * be delivered to all threads in the process? * deliver the signal only to the thread to which it applies? * deliver the signal to certain threads in the process? * Assign a specific thread to handle all signals for the process?