Critical Sections

The essence of the problem is as follows: Processes are interrupted at points where they shouldn't be if they are to do their work correctly. Obviously, a potential solution is to mark the relevant code section so that it can no longer be interrupted by the scheduler. Although this approach would work in principle, there are several inherent problems. Under certain circumstances, a faulty program would be unable to find its way out of the marked code section and would fail to relinquish the CPU, thus making the computer unusable. We must therefore reject this solution out of hand.1

The solution to the problem does not necessarily require that the critical section not be interrupted. Processes may well be interrupted in a critical section as long as no other process enters the section. This strict prohibition ensures that values cannot be changed by several processes at the same time and is referred to as mutual exclusion. Only one process may enter a critical area of code at a given time.

There are many ways of designing a mutual exclusion method of this kind (regardless of the technical implementation). However, all must ensure that the exclusion principle functions under all circumstances. It must depend neither on the number nor on the speed of the processors involved. If this were the case (and the solution were therefore only available on a given computer system with a specific hardware configuration), the solution would be impracticable because it would not provide general protection — and this is exactly what is needed. Processes should not be allowed to block each other and come to a permanent stop. Although this is a desirable goal, it cannot always be achieved by technical means as you will see below. It is often up to the programmer to think ahead so that the problem does not occur.

Which principles are applied to support a mutual exclusion method? A multitude of different solutions have been proposed in the history of multitasking and multiuser systems, all with their specific

1 The kernel itself can (and must) reserve the right to disable interrupts at certain points to seal itself off completely from external or periodic events. This is not, however, possible for user processes.

advantages and disadvantages. Some solutions are of an academic nature, and some have found their way into practice in various operating systems — one solution has been adopted in most systems and is therefore worth discussing in detail.

Continue reading here: Semaphores

Was this article helpful?

0 0