PROCESSES AND THREADS

Processes and Threads

We can think of a thread as basically a lightweight process. In order to understand this let us consider the two main characteristics of a process:

Unit of resource ownership

-- A process is allocated:

·         a virtual address space to hold the process image

·         control of some resources (files, I/O devices...)

Unit of dispatching

- A process is an execution path through one or more programs:

·         execution may be interleaved with other processes

·         the process has an execution state and a dispatching priority 

If we treat these two characteristics as being independent (as does modern OS theory):

• The unit of resource ownership is usually referred to as a process or task. This Processes have:
• a virtual address space which holds the process image.
• protected access to processors, other processes, files, and I/O resources.
• The unit of dispatching is usually referred to a thread or a lightweight process. Thus a thread:
• Has an execution state (running, ready, etc.)
• Saves thread context when not running
• Has an execution stack and some per-thread static storage for local variables
• Has access to the memory address space and resources of its process
• all threads of a process share this when one thread alters a (non-private) memory item, all other threads (of the process) sees that a file open with one thread, is available to others

Benefits of Threads vs Processes

If implemented correctly then threads have some advantages of (multi) processes, They take:

• Less time to create a new thread than a process, because the newly created thread uses the current process address space.
• Less time to terminate a thread than a process.
• Less time to switch between two threads within the same process, partly because the newly created thread uses the current process address space.
• Less communication overheads -- communicating between the threads of one process is simple because the threads share everything: address space, in particular. So, data produced by one thread is immediately available to all the other threads.

Multithreading vs. Single threading

Just a we can multiple processes running on some systems we can have multiple threads running:

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

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 

Multithreading your code can have many benefits:

• 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 semi-independent 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.