Linux process synchronization Mechanism _ turn

Turn from: Linux process synchronization mechanism

Specific applications can be consulted: thread synchronization of the IPC signal volume

In order to effectively control the process of communication between multiple processes, ensure the orderly and harmonious communication process, the OS must provide a certain synchronization mechanism to ensure that the process is not self-speaking but effective collaborative work. For example, in the shared memory of the communication mode, two or more processes to the shared memory for data writing, then how to ensure that a process in the process of writing is not interrupted by other processes, to ensure the integrity of the data? How to ensure that the reading process in the process of reading data will not change, to ensure that the data read is complete and effective?
Common synchronization methods are: mutexes, condition variables, read and write locks, record locks (file locks), and semaphores.

1, mutual exclusion lock

As the name implies, a lock is used to lock something, and only the person with the key can have control over what is locked (the thief who steals the lock is not in our scope of discussion). The so-called mutual exclusion, literally understood is mutually exclusive. So the mutex literally understands that a bit of process has this lock, it will repel all the other processes to access the locked thing, and the other process can only wait if a lock is needed, wait for the lock to open before it can continue to run.
In implementation, a lock is not associated with a specific variable, it is itself a separate object. The incoming (line) process obtains this object when it is needed, and releases it when it is not needed.
The main feature of the mutex is that the release of the mutex must be released by a locked-in (line) path, and if the incoming (line) path with the lock is not released, then the other incoming (line) path never gets a chance to obtain the required mutex. mutexes are primarily used for synchronization between threads.

2. Condition variables

As mentioned above, for a mutex, if the incoming (line) thread with the lock does not release the lock, the other incoming (line) path never gets a lock, and there is never a chance to continue with the subsequent logic. In the real world, a thread a needs to change the value of a shared variable x, in order to ensure that in the process of modification x will not be modified by other threads, thread a must first obtain a lock on X. Now if a has been locked, because the business logic needs, only if the value of x is less than 0 o'clock, thread A can perform subsequent logic, so thread a must release the mutex and then continue to "busy". As shown in the following pseudo-code:

get x Lock0) {//////    get x Lock}// unlock x   

This approach is compared to consuming the resources of the system, because the process must be actively acquiring locks, checking x conditions, releasing locks, acquiring locks, re-checking, and releasing them until the conditions of operation are met. So we need a different kind of synchronization, when thread X discovers that the locked variable does not meet the criteria, it automatically releases the lock and puts itself in a wait state, giving the CPU control to the other threads. Other threads now have the opportunity to modify the value of X, and then notify those threads that are stuck in a wait state because the condition is not satisfied. This is a notification model of synchronization, greatly saving the CPU computing resources, reduce the competition between the threads, and improve the efficiency of the system between the threads. This type of synchronization is a conditional variable.
Frankly speaking, the four words "conditional variables" are not very easy to understand from the literal meaning. We can think of a "condition variable" as an object, a bell, a ringing bell. When a thread obtains a mutex, the thread releases the mutex and hangs itself on the "bell" because the locked variable does not satisfy the condition that it continues to run. After the other thread modifies the variable, it shakes the "bell" and tells the hanging thread: "The things you have been waiting for have changed, wake up and see if it satisfies your requirements now." So the hanging threads knew that they would wake up and see if they could keep running.

3. Read/write Lock

The mutex is an exclusive lock, and the combination of the conditional variable and the mutex can effectively save the system resources and improve the cooperative productivity among the threads. The purpose of the mutex is to monopolize, and the purpose of the condition variable is to wait and notify. But the real world is very complex di, the problem we have to solve is also a variety of Di. Functionally, mutexes and conditional variables can solve essentially all problems, but performance is not necessarily completely satisfied. People's endless desire to create a more targeted, better performance of the synchronization mechanism. Read-write locks are such a thing.
Consider a file with more than one process to read the contents of, but only 1 processes have write requirements. We know that reading the contents of a file does not change the contents of the file, so that even if multiple processes are reading the same file at the same time, everyone can coexist harmoniously. When the writing process needs to write data, in order to ensure the consistency of the data, all the reading process can not read the data, otherwise it is likely to read the data half is old, half is new situation, the logic is lost.
To prevent the reading of data from being written to new data, the read process must add a lock to the file. Now if we have 2 processes that read at the same time, if we use the mutex and condition variables above , when one of the processes is reading the data, the other process can only wait because it is not locked. From a performance consideration, the time spent waiting for a process is completely wasted, because the process can read the contents of the file without affecting the first, but the process is not locked, so it can do nothing, only wait until the flowers are thanked.
So, we need a different type of synchronization to meet the above requirements, which is the read-write lock.
The emergence of read-write lock can effectively solve the problem of multi-process parallel reading. Every process that needs to be read requests a read lock so that everyone does not interfere. When there is a process that needs to write like data, first apply for a write lock. If a read (or write) lock is found at the time of application, the write process must wait until all of the read (write) locks are fully released. The read process first requests a read lock before reading, and if the read data is locked by a write lock, the read process must also wait for the read lock to be released.
Naturally, multiple read locks can coexist, but write locks are completely mutually exclusive.

4. Record lock (File lock)

To increase parallelism, we can further subdivide the granularity of locked objects on the basis of read-write locks. For example, in a file, the read process may need to read the first 1k bytes of the file, and the write process needs to write the last 1k bytes of the file. We can read the lock on the first 1k bytes, write a lock on the last 1k, so that two processes can work concurrently. The so-called "record" in the record lock is actually the concept of "content". A read-write lock can be used to lock part, not the entire file.
A file lock can be considered a special case of a record lock, and when all the contents of a file are locked with a record lock, the record lock can be called a file lock at this time.

5. Signal

The semaphore can be said to be an upgraded version of the conditional variable. The condition variable is equivalent to the bell, and each pending process also needs to obtain a mutex and determine if the required conditions are met, and the semaphore combines the two steps together.
In the posix.1 rationale, it is claimed that the reason for a semaphore with a mutex and condition variable is: "The main purpose of this standard to provide a semaphore is to provide a way of synchronizing between processes; These processes may or may not share memory areas. Mutexes and condition variables are described as synchronization mechanisms between threads, which always share (a) memory area. Both of these have been used for many years in a synchronized manner. Each group of primitives is particularly suited to specific problems. " Although the intent of a semaphore is inter-process synchronization, the intent of the mutex and condition variables is to synchronize between threads, but semaphores can also be used between threads, and mutexes and condition variables can also be used between processes. decisions should be made on the basis of actual circumstances.
The most useful scenario for a semaphore is to indicate the number of available resources. For example, an array with 10 elements, we can create a semaphore with an initial value of 0. Whenever a process needs to read the elements of a group (assuming that only 1 elements can be fetched at a time), apply for the semaphore (the value of the signal is reduced by 1), and when a process needs to write the element, the request hangs the signal ( Signal value plus 1). This way the semaphore plays a role in the amount of available resources. If we limit the value of a semaphore to only 0 and 1, it is the same as the meaning of the mutex.

Linux process synchronization Mechanism _ turn