Docstoc

THREAD

Document Sample
THREAD Powered By Docstoc
					CSc 452 -- Spring 1999

Threads vs. Processes

Topic 19: Threads vs. Processes Reading: Tanenbaum 12.1-12.1.4 • The process abstraction is a convenient way of allowing multiple computations to share a single computer. A process consists of a sequential execution stream (processor state), a virtual address space, and the state of the resources the computation is using (open files, current working directory, etc.). • Processes are useful because they provide each computation with its own virtual machine, allowing computations to be independent. • Processes are relatively heavy-weight, however, since there is a lot of work involved in creating and destroying processes, and switching between them. The process abstraction may also not be suitable for all applications, since cooperating processes may not need nor want separate address spaces. • A lighter-weight abstraction is that of the thread, which is simply a sequential execution stream (thread of control). Multiple threads can share the same address space and other resources -- a collection of such threads is called a process or a task. • Each thread has its own stack and processor state. • Unlike processes, the threads of a task are not independent. They share an address space, and thus there is no protection between

19-1

CSc 452 -- Spring 1999

Threads vs. Processes

them. This is ok because the threads are part of the same task. • Synchronization mechanisms such as semaphores and monitors require threads (shared memory). • In USLOSS, what we’ve been calling “processes” are actually threads within the address space of the UNIX process that runs USLOSS. • Why write a multi-threaded application? • Multiple threads allow a single task to overlap computation and I/O. • One thread computes, while another waits for I/O to complete. Consider a web server that handles many clients. • Multiprogramming only overlaps computation and I/O of different processes. This improves system throughput, but not the running time of individual tasks. • Simplified programming (e.g., producer/consumer). Some problems are easier solved by cooperating threads, rather than by a single process that does everything. • Parallel computation on multiple processors (more on this later). The computation is done by many threads, allowing many processors to be used. • Where should threads be implemented? • User-level (library): • OS implements processes -- processor state and address space.
19-2

CSc 452 -- Spring 1999

Threads vs. Processes

• Library (thread package) implements threads, thread locking/ synchronization, and thread scheduling. • Advantages: • Fast context switch between threads (no system calls). • Application-specific thread scheduling. • Application-specific locking and synchronization. • Disadvantages: • OS schedules processes, which may interfere with thread scheduling. In particular, if one thread blocks for I/O the whole process blocks (and all of the threads it contains), undermining one of the reasons for having threads. • Threads share OS resources such as open files, etc. May be too inflexible. • It is difficult for a user-level scheduler to implement a time quantum. Threads must voluntarily give up control of the processor by invoking the scheduler. • Kernel-level (in the OS): • OS separates processor state from address spaces. • Advantages and disadvantages are opposites of user-level threads. • Hybrid (scheduler activations) [CACM Feb 1992] • Implement kernel-level threads (activations) on top of user-level threads. • Each process gets one kernel-level thread for each processor it is
19-3

CSc 452 -- Spring 1999

Threads vs. Processes

allocated. • OS allocates processors to processes. Process is notified (scheduler invoked (’activated’)) when activation is added or taken away. • New activation invokes scheduler, runs user-level thread. • “Messenger” activation invokes scheduler to save state of userlevel thread running on activation taken away. • Process tells OS when processor needs change. • OS notifies process when an activation blocks for I/O. • New activation saves state of blocked user-level thread, runs a different thread. • This organization provides the best of both worlds. The application handles all of the details (policy), while the OS provides the information on which the policy is based (mechanism). • A multi-threaded program is often difficult to implement and debug. If all you want to do is overlap computation and I/O it is often simpler to use asynchronous I/O. • So far we have dealt with synchronous I/O, which causes a process that issues an I/O request to be blocked until the I/O completes. • Alternatively, a process could issue the I/O request, then continue processing.

19-4

CSc 452 -- Spring 1999

Threads vs. Processes

• Process obviously can’t assume I/O is complete when call returns. • Process may later wait for I/O to complete via a system call. • Process may also be notified of I/O completion via a signal (asynchronous jump, much like an interrupt). • Asynchronous I/O is often simpler to implement in the OS and has less overhead than solution based on threads or processes, but usually makes the application more complex. • A third approach is to rely on the OS to do the overlap. Read-ahead and write-behind can be very effective at overlapping the computation and I/O of a single computation. • Prefetching (read-ahead) is a hot research topic. Techniques for predicting the future: • Static analysis (compiler support) • Programmer-provided directives or hints • Record behavior of previous runs • Speculative execution • To summarize, threads are lighter weight than processes. A user-level implementation is preferable to a kernel-level, although a hybrid approach provides the best results.

19-5

CSc 452 -- Spring 1999

Threads vs. Processes

19-6


				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:92
posted:8/18/2009
language:English
pages:6