Critical area problem of Process Synchronization and Peterson Algorithm

1. Background first, let's look at an example. Process P1 and P2 share a variable COUNT with the initial value 0.

The execution sequence of processes P1 and P2 is random and may be sequential or concurrent. As shown in the figure, the value of COUNT varies depending on the execution sequence, this is not allowed. In this case, and concurrent access and operation of the same data by multiple processes, and the execution result is related to the specific sequence of access, it is called a competitive condition.
2. The concept of critical zone is introduced to avoid the above situation. A system has n processes, and each process has a code segment called a critical section. An important feature of this system is that when a process is executed in the critical section, no other process is allowed to be executed in the critical section. Critical Zone problems must meet three principles: Mutual Exclusion, forward, and limited wait. Explanation:

3. After learning about the critical section, the Peterson algorithm controls the two processes to access a shared unit of user resources without access conflicts. The Peterson algorithm is a concurrent programming algorithm that implements mutex. It solves this problem well. First, let's look at two programs that are not using this algorithm.

By carefully analyzing the above two pieces of code, we can know that when multiple processes execute code, they all violate the SS principle (the three original principles in the critical section ). The Peterson algorithm code is as follows: it satisfies the three original principles in the critical section. The median turn is used to avoid it.
Pi process pj process (switch I and j)


Pseudocode
Java code implementation

Public class Peterson implements Runnable {private static boolean [] in = {false, false}; private static volatile int turn =-1; public static void main (String [] args) {new Thread (new Peterson (0), "Thread-0 "). start (); new Thread (new Peterson (1), "Thread-1 "). start ();} private final int id; public Peterson (int I) {id = I;} private int other () {return id = 0? 1: 0 ;}@ Override public void run () {in [id] = true; turn = other (); while (in [other ()] & turn = other () {System. out. println ("[" + id + "]-Waiting... ");} System. out. println ("[" + id + "]-Working (" + ((! In [other ()])? "Other done": "my turn") + "); in [id] = false ;}} if you want to learn more about the Peterson algorithm, visit the following website:Http://zh.wikipedia.org/wiki/Peterson%E7% AE %97%E6%B3%95 Http://stackoverflow.com/questions/2911915/peterson-algorithm-in-java4. When critical resources are mentioned above, it is necessary to mention critical resources. Although various processes in multiple program systems can share various types of resources, critical resources can only be used by one process at a time, and can be used by other processes only after being used. (For example, the COUNT in the preceding example is a critical resource.) a process must be mutually exclusive to the critical resource. To achieve mutually exclusive access to the critical resource, ensure that all processes are mutually exclusive to their critical zones. Therefore, before entering the critical section of a process, you must apply for a process before entering the critical section. The principle that the synchronization mechanism should follow: when idle allows a non-process to be in a critical zone, a process that requires entry into the critical zone must be immediately entered to make effective use of critical resources. If you are busy, wait. When an existing process is in the critical section, other processes that attempt to enter the critical section must wait to ensure that they enter the critical section. For processes requiring entry into the critical zone, the process should be entered within a limited period of time to avoid "death ". For a process waiting to enter the critical section, it must release the processor immediately to avoid the process being "busy"

To solve the mutex lock mechanism: a software method for implementing mutex is to adopt the lock mechanism, that is, to provide a pair of lock and unlock primitives, and before a variable W enters the critical section, the variables are used to determine whether critical resources are occupied.
However, the lock mechanism can only represent the "on" and "off" states. The Open and Close primitives must be used as atomic operations. Shutting down the original retesting W State wastes processing time; the lock mechanism can only resolve mutex and cannot be used for synchronization. The signal synchronization mechanism solves this problem well. The next blog (Process Synchronization semaphore mechanism (pv operation) and three typical synchronization problems) will explain the semaphore mechanism in detail.