Explain the concepts of threads and processes in operating system?

Threads and processes are an important part of the operating systems that have features of multi–tasking and parallel programming. These come under the sole concept of ‘scheduling’. Let us try to understand these concepts with the help of an analogy.

- Consider the process to be a house and threads are its occupants. 

- Then, process is like a container having many attributes. 

- These attributes can be compared to that of a house such as number of rooms, floor space and so on. 

- Despite having so many attributes, this house is a passive thing which means it can’t perform anything on its own. 

- The active elements in this situation are the occupants of the home i.e., the threads. 

- The various attributes of the house are actually used by them. 

- Since you too live in a house you must have got an idea how it actually works and behaves. 

- You do whatever you like in the house if only you are there. 

- What if another person starts living with you? You just can’t do anything you want to do. 

- You cannot use the washroom without making sure that the other person is not there. 

- This can be related to multi – threading. 

- Just as a part of estate is occupied by the house, an amount of memory is occupied by the process. 

- Just as the occupants are allowed to freely access anything in the house, similarly the occupied memory is utilized by the threads that are a part of that process i.e., the access to memory is common. 

- If one process allocates some memory, it can be accessed by all other threads also. 

- If such a thing is happening, it has to be made sure that from all the threads, the access to the memory is synchronized. 

- If it cannot be synchronized, then it becomes clear that the memory has been allocated specifically to a thread. 

- But in actual, things are a lot more complicated because at some point of time everything has to be shared. 

- If one thread wants to use some resource that is already under use by some other thread, than that thread has to follow the concept of mutual exclusion. 

- An object known as the mutex is used by the thread for achieving exclusive access to that resource. 

- Mutex can be compared to a door lock. 

- Once a thread locks this, no other thread can use that resource until the mutex is again unlocked by that thread. 

- Mutex is one resource that a thread uses. 

- Now, suppose there are many threads waiting to use the resource when mutex is unlocked, the question that arises now is that who will be next one to use the resource. 

- This problem can be solved by either deciding on the basis of length of wait or on basis of priority. 

- Suppose there is a location that can be accessed by more than one threads simultaneously.

- You want to have only a limited number of threads using that memory location at any given point of time. 

- This problem cannot be solved by mutex but with another resource called semaphore. 

- Semaphore with a count of 1 is the resource that can only be used by one thread at a time. 

- In semaphore of greater count more threads can access it simultaneously.  

- It just depends up on how you characterize or set the lock.

Critical Regions

A critical region is a section of code that is always executed under mutual exclusion. Critical regions shift the responsibility for enforcing mutual exclusion from the programmer(where it resides when semaphores are used) to the compiler.
They consist of two parts:
- Variables that must be accessed under mutual exclusion.
- A new language statement that identifies a critical region in which the variables
are accessed.
var
v : shared T;
...
region v do
begin
...
end;
All critical regions that are ‘tagged’ with the same variable have compiler-enforced mutual exclusion so that only one of them can be executed at a time:
Process A:
region V1 do
begin
{Do some stuff.}
end;
region V2 do
begin
{Do more stuff.}
end;

Process B:
region V1 do
begin
{Do other stuff.}
end;
Here process A can be executing inside its V2 region while process Bis executing inside its V1 region, but if they both want to execute inside their respective V1 regions only one will be permitted to proceed.

Overview Of Mutual Exclusions in Operating Systems

A way of making sure that if one process is using a shared modifiable data, the other processes will be excluded from doing the same thing.
Formally, while one process executes the shared variable, all other processes desiring to do so at the same time moment should be kept waiting; when that process has finished executing the shared variable, one of the processes waiting; while that process has finished executing the shared variable, one of the processes waiting to do so should be allowed to proceed. In this fashion, each process executing the shared data (variables) excludes all others from doing so simultaneously. This is called Mutual Exclusion.
Mutual exclusion (often abbreviated to mutex) algorithms are used in concurrent programming to avoid the simultaneous use of a common resource, such as a global variable, by pieces of computer code called critical sections. A critical section is a piece of code where a process or thread accesses a common resource. The critical section by itself is not a mechanism or algorithm for mutual exclusion. A program, process, or thread can have critical section in it without any mechanism or algorithm, which implements mutual exclusion.
Examples of such resources are fine-grained flags, counters or queues, used to communicate between code that runs concurrently, such as an application and its interrupt handlers. The problem is acute because a thread can be stopped or started at any time.

How Mutual Exclusion is Done ?
We need to stop the two threads from working on the same data at the same time. The most common way to do this today is by using locks. A lock can be either locked or unlocked. As long as you do not forget to lock or unlock the door, this algorithms guarantees mutual exclusion and protects the so called critical region.
C:
1. omp_set_lock (&my_lock);
2. i++;
3. omp_unset_lock (&my_lock);
Actually, the lock needs to be initialized beforehand and destroyed sometime afterwards as well, but that's not too difficult either.
C:
1. #pragma omp critical
2. {
3. i++;
4. }
Or even simpler, like this:
C:
1. #pragma omp atomic
2. i++;
This basically does the same thing, except you do not need to worry about initialization and destruction of the lock and you cannot forget to unlock the mutex accidentally.