Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Library (computing) wikipedia , lookup
Copland (operating system) wikipedia , lookup
Plan 9 from Bell Labs wikipedia , lookup
Security-focused operating system wikipedia , lookup
Distributed operating system wikipedia , lookup
Unix security wikipedia , lookup
Spring (operating system) wikipedia , lookup
Burroughs MCP wikipedia , lookup
Threading A thread is a single sequence stream within in a process. Because threads have some of the properties of processes, they are sometimes called lightweight processes. In a process, threads allow multiple executions of streams. In many respect, threads are popular way to improve application through parallelism. The CPU switches rapidly back and forth among the threads giving illusion that the threads are running in parallel. Like a traditional process i.e., process with one thread, a thread can be in any of several states (Running, Blocked, Ready or Terminated).Processes are used to group resources together and threads are the entities scheduled for execution on the CPU. Each thread has its own stack. Since thread will generally call different procedures and thus a different execution history. This is why thread needs its own stack. An operating system that has thread facility, the basic unit of CPU utilization is a thread. A thread has or consists of a program counter (PC), a register set, and a stack space. Threads are not independent of one other like processes as a result threads shares with other threads their code section, data section, OS resources also known as task, such as open files and signals. Depending on the OS, threads may have some other private resources too, such as thread-local storage (effectively, a way of referring to "variable number X", where each thread has its own private value of X). The OS will generally attach a bit of "housekeeping" information to each thread, such as its priority and state (running, waiting for I/O etc). Processes Vs Threads Similarities Like processes threads share CPU and only one thread active (running) at a time. Like processes, threads within a process, threads within a process execute sequentially. Like processes, thread can create children. And like process, if one thread is blocked, another thread can run. Differences Unlike processes, threads are not independent of one another. Unlike processes, all threads can access every address in the task. Unlike processes, threads are design to assist one other. Note that processes might or might not assist one another because processes may originate from different users. Why Threads? 1. A process with multiple threads makes a great server for example printer server. 2. Because threads can share common data, they do not need to use interprocess communication. 3. Because of the very nature, threads can take advantage of multiprocessors. Threads are cheap in the sense that 1. They only need a stack and storage for registers therefore, threads are cheap to create. 2. Threads use very little resources of an operating system in which they are working. That is, threads do not need new address space, global data, program code or operating system resources. 3. Context switching is fast when working with threads. The reason is that we only have to save and/or restore PC, SP and registers. But this cheapness does not come free - the biggest drawback is that there is no protection between threads. Advantages of Threads over Multiple Processes Context Switching Threads are very inexpensive to create and destroy, and they are inexpensive to represent. For example, they require space to store, the PC, the SP, and the general-purpose registers, but they do not require space to share memory information, Information about open files of I/O devices in use, etc. With so little context, it is much faster to switch between threads. In other words, it is relatively easier for a context switch using threads. Sharing Treads allow the sharing of a lot resources that cannot be shared in process, for example, sharing code section, data section, Operating System resources like open file etc. Disadvantages of Threads over Multiprocesses Blocking The major disadvantage if that if the kernel is single threaded, a system call of one thread will block the whole process and CPU may be idle during the blocking period. Security Since there is, an extensive sharing among threads there is a potential problem of security. It is quite possible that one thread over writes the stack of another thread (or damaged shared data) although it is very unlikely since threads are meant to cooperate on a single task. Single threading (when the OS does not recognize the concept of thread) Multithreading (when the OS supports multiple threads of execution within a single process) On a single processor, multithreadin g generally occurs by time-division multiplexing (as in multitasking) : the processor switches between different threads. This context switching generally happens frequently enough that the user perceives the threads or tasks to be running at the same time. On a multiprocessor or multi-core system, the threads or tasks will generally run at the same time, with each processor or core running a particular thread or task. Support for threads in programming languages varies: a number of languages simply do not support having more than one execution context inside the same program executing at the same time. Examples of such languages include Python, and OCaml, because the parallel support of their runtime support is limited by the use of a central lock, called "Global Interpreter Lock" in Python, "master lock" in Ocaml. Many modern operating systems directly support both time-sliced and multiprocessor threading with a process scheduler. The operating system kernel allows programmers to manipulate threads via the system call interface. Some implementations are called a kernel thread, whereas a lightweight process (LWP) is a specific type of kernel thread that shares the same state and information. MS-DOS: support a single user process and a single thread UNIX: supports multiple user processes but only supports one thread per process Solaris: supports multiple threads Advantages of Multithreading: Improve application responsiveness -- Any program in which many activities are not dependent upon each other can be redesigned so that each activity is defined as a thread. For example, the user of a multithreaded GUI does not have to wait for one activity to complete before starting another. Use multiprocessors more efficiently -- Typically, applications that express concurrency requirements with threads need not take into account the number of available processors. The performance of the application improves transparently with additional processors. Numerical algorithms and applications with a high degree of parallelism, such as matrix multiplications, can run much faster when implemented with threads on a multiprocessor. Improve program structure -- Many programs are more efficiently structured as multiple independent or semiindependent units of execution instead of as a single, monolithic thread. Multithreaded programs can be more adaptive to variations in user demands than single threaded programs. Use fewer system resources -- Programs that use two or more processes that access common data through shared memory are applying more than one thread of control. However, each process has a full address space and operating systems state. The cost of creating and maintaining this large amount of state information makes each process much more expensive than a thread in both time and space. In addition, the inherent separation between processes can require a major effort by the programmer to communicate between the threads in different processes, or to synchronize their actions. The thread scheduler There are generally more threads than CPUs. Part of a multithreaded system is therefore a thread scheduler, responsible for sharing out the available CPUs in some way among the competing threads. Note that in practically all modern operating systems, the thread scheduler is part of the OS itself. So the OS actually "sees" our different threads and is responsible for the task of switching between them2. The rationale for handling threading "natively" in the OS is that the OS is likely to have the information to make threading efficient (such as knowing which threads are waiting for I/O and for how long), whereas a software library may not have this information available. In the rest of our discussion, we'll generally assume this native threads model. Operating systems schedule threads in one of two ways. Preemptive multithreading is generally considered the superior approach, as it allows the operating system to determine when a context switch should occur. Cooperative multithreading, on the other hand, relies on the threads themselves to relinquish control once they are at a stopping point. This can create problems if a thread is waiting for a resource to become available. The disadvantage to preemptive multithreading is that the system may make a context switch at an inappropriate time, causing priority inversion or other negative effects which may be avoided by cooperative multithreading. Traditional mainstream computing hardware did not have much support for multithreading as switching between threads was generally already quicker than full process context switches. Processors in embedded systems, which have higher requirements for real-time behaviors, might support multithreading by decreasing the thread switch time, perhaps by allocating a dedicated register file for each thread instead of saving/restoring a common register file. In the late 1990s, the idea of executing instructions from multiple threads simultaneously has become known as simultaneous multithreading. This feature was introduced in Intel's Pentium 4 processor, with the name hyper threading Thread Levels There are two broad categories of thread implementation: User-Level Threads -- Thread Libraries. Kernel-level Threads -- System Calls. There are merits to both, in fact some OSs allow access to both levels (e.g. Solaris). User-Level Threads (ULT) In this level, the kernel is not aware of the existence of threads -- All thread management is done by the application by using a thread library. Thread switching does not require kernel mode privileges (no mode switch) and scheduling is application specific Kernel activity for ULTs: The kernel is not aware of thread activity but it is still managing process activity When a thread makes a system call, the whole process will be blocked but for the thread library that thread is still in the running state So thread states are independent of process states Advantages and inconveniences of ULT Advantages: Thread switching does not involve the kernel -- no mode switching Scheduling can be application specific -- choose the best algorithm. ULTs can run on any OS -- Only needs a thread library Disadvantages: Most system calls are blocking and the kernel blocks processes -- So all threads within the process will be blocked The kernel can only assign processes to processors -- Two threads within the same process cannot run simultaneously on two processors Kernel-Level Threads (KLT) In this level, All thread management is done by kernel No thread library but an API (system calls) to the kernel thread facility exists. The kernel maintains context information for the process and the threads, switching between threads requires the kernel Scheduling is performed on a thread basis. Advantages and inconveniences of KLT Advantages the kernel can simultaneously schedule many threads of the same process on many processors blocking is done on a thread level kernel routines can be multithreaded Disadvantages: Thread switching within the same process involves the kernel, e.g. if we have 2 mode switches per thread switch this results in a significant slow down. Combined ULT/KLT Approaches Idea is to combine the best of both approaches Solaris is an example of an OS that combines both ULT and KLT Thread creation done in the user space Bulk of scheduling and synchronization of threads done in space The programmer may adjust the number of KLTs Process includes the user's address space, stack, process control block User-level threads (threads library) invisible to are the interface for application parallelism Kernel threads the unit that can be dispatched on processor the user and the OS a Lightweight processes (LWP) each LWP supports one or more ULTs and maps to exactly one KLT Processes, kernel threads, user threads, and fibers A process is the "heaviest" unit of kernel scheduling. Processes own resources allocated by the operating system. Resources include memory, file handles, sockets, device handles, and windows. Processes do not share address spaces or file resources except through explicit methods such as inheriting file handles or shared memory segments, or mapping the same file in a shared way. Processes are typically preemptively multitasked. A kernel thread is the "lightest" unit of kernel scheduling. At least one kernel thread exists within each process. If multiple kernel threads can exist within a process, then they share the same memory and file resources. Kernel threads are preemptively multitasked if the operating system's process scheduler is preemptive. Kernel threads do not own resources except for a stack, a copy of the registers including the program counter, and thread-local storage (if any). Threads are sometimes implemented in userspace libraries, thus called user threads. The kernel is not aware of them; they are managed and scheduled in userspace. Some implementations base their user threads on top of several kernel threads to benefit from multi-processor machines (N: M model). In this article the term "thread" (without kernel or user qualifier) defaults to referring to kernel threads. User threads as implemented by virtual machines are also called green threads. Fibers are an even lighter unit of scheduling which are cooperatively scheduled: a running fiber must explicitly "yield" to allow another fiber to run, which makes their implementation much easier than kernel or user threads. A fiber can be scheduled to run in any thread in the same process. This permits applications to gain performance improvements by managing scheduling themselves, instead of relying on the kernel scheduler (which may not be tuned for the application). Parallel programming environments such as OpenMP typically implement their tasks through fibers. Application that Benefits from Threads In general, any program that has to do more than one task at a time could benefit from multitasking. For example, a program that reads input, process it, and outputs could have three threads, one for each task. Example: A file server on a LAN A proxy server satisfying the requests for a number of computers on a LAN would be benefited by a multi-threaded process. It needs to handle several file requests over a short period Hence more efficient to create (and destroy) a single thread for each request Multiple threads can possibly be executing simultaneously on different processors Example 2: Matrix Multiplication Matrix Multiplication essentially involves taking the rows of one matrix and multiplying and adding corresponding columns in a second matrix i.e.: Application that cannot Benefit from Threads Any sequential process that cannot be divided into parallel task will not benefit from thread, as they would block until the previous one completes. For example, a program that displays the time of the day would not benefit from multiple threads.