1. Mutual Exclusion: It says that at a particular time only one process can enter into the critical section.
2. Progress: One process cannot stop another process for entering into the critical section.
3. Bounded Waiting: If more than one process wants to enter into the critical section then one process will give chance to another process after taking a finite number of chances itself.
4. Portability OR Architectural Neutrality: The solution or the mechanism should be independent of architecture.

Example: X is a kernel data structure which contains the list of open files. So, if two processes open files simultaneously then separate updates to this list can result in Race Condition.

However, if categorized, there are only 2 approaches for handling the critical section in OS(kernel).

1. Preemptive kernel: This type of kernel is used many OS’s out there and is real-time, responsive, preferable and every Linux Kernel above version 2.6 is a Preemptive Kernel.
2. Non-Preemptive kernel: This type of kernel is completely free from such kind of problems.

Note: Every solution is based on some kind of LOCK.

The following are few mechanisms available to avoid or remove the critical section problem:

• Peterson’s Solution
• Sync Hardware: disable interrupts by another process when a process is in the critical section; this approach is taken by non-preemptive kernels; but, this is only good for single processors; not good for multi-processors, as disabling interrupts on a multi-processor is a time-consuming process.
• Test and Set Lock: an atomic instruction provided directly by hardware; only good for the multi-processor system; it is a complicated solution for hardware designers to implement and hard for software programmers to use; so to overcome these problems, semaphores came to picture
• Mutex Locks: Mut + Ex = mutual exclusion solution; software solution for the critical section problem; used to prevent critical regions and this prevents Race Conditions; Disadvantages: requires Busy Waiting, which wastes CPU-time, also called SPIN-LOCK because another process keeps spinning on acquire(), this continued looping is also a problem in TestAndSet(); Advantages: often used in the multi-processor system because only one thread can “spin” on one processor and other can run on another, no context switch is required because context switches can waste time (reasonable time) but when a LOCK is expected to be held for short time, they are useful; Although, this is a simple solution but now we will look at some more Robust Tool = Semaphores.
• Semaphores: although a semaphore variable helps to solve several problems still they have a problem of Busy Waiting.

Solution/Modification for semaphore in order to remove the “Busy Waiting” problem.

The waiting process (basically spinning) should go to sleep() = Waiting Queue / Blocks Itself and when the 1st process comes out of the critical section, then it comes out of sleep by executing wakeup() = Read Queue and after that CPU scheduling algorithms are used in order to give it a CPU control.

Semaphore basically have two things:

1. Value = value can be anything in accordance with the problem and situation.
2. List = process is added to this list when it goes waiting and signal() = removes it from it and awakens that process.

Following is code for the modified version of wait() for a semaphore:

wait(semaphore *S) {
S -> value --;
if (S -> value < 0) {
add this process to S -> list;
block(); // Suspend = system call
 }
}

Following is code for the modified version of signal() for a semaphore:

signal(semaphore *S) {
S -> value++;
if(S -> value = 0) {
remove a process P from S-> list;
wakeup(P); // Resume = system call
 }
}

Differences between a normal semaphore and a modified semaphore:

1. Classic Semaphore = its value can never be negative (-ve)
2. Modified Semaphore = its value can be negative(-ve) and whatever the value is in negative it simply states that those number of processes are waiting on that semaphore.

Now modified version of semaphore states that:

1. Value = it can be anything.
2. Pointer to a list of PCBs = to ensure Busy Waiting (FIFO Queue is used).