Linux IPC Practice (1)--Overview

synchronization and mutual exclusion of processes

Process synchronization: Multiple processes need to work together to accomplish a task.

process Mutex: Because each process requires the sharing of resources, and some resources need to be mutually exclusive use, so the process of competition between the use of these resources, the process of this relationship is a process of mutual exclusion; some resources in the system allow only one process at a time, which is called a critical or mutex resource. The program segment that involves the mutex in the process is called the critical section.

Linux IPC Development

The process communication methods under Linux are basically inherited from the process communication methods on the UNIX platform. The two main players at T - Lab and BSD(UC Berkeley's Berkeley Software Release Center), which have made significant contributions to the development of UNIX, have a different focus on inter-process communication. The former is a systematic improvement and expansion of the inter-process communication means of UNIX, which forms "system V IPC", whose communication process is confined to a single computer, while BSD skips the limit, which forms a socket-based interface (socket) . Inter-process communication mechanism. Linux, in turn, has inherited both advantages.

Inter-process Communication classification

File

File Lock

Piping (pipe) and Named pipes (FIFO)

Signal (signal)

Message Queuing

Shared Memory

Signal Volume

Mutex Amount

Condition Variable

read/write lock

socket (socket)

ways to share information among processes

The persistence of IPC objects

with process persistence : persists until the last process that is opened ends. (such as pipe and FIFO (process end, data deletion))

Persistent with kernel : persists until kernel bootstrap or explicit deletion (such as System V Message Queuing, shared memory, semaphores)

persists with file system : persists until explicitly deleted , even if kernel bootstrap exists. (POSIX Message Queuing, shared memory, semaphore if it is implemented using a mapping file )

[IPC objects are managed by the Linux kernel]

process Deadlock and processing

A deadlock is a phenomenon in which multiple processes wait for each other's resources, and do not release their resources until they are available to them, thus causing a cyclic wait. If all the processes are waiting for something that cannot happen, the process is deadlocked.

Four necessary conditions for deadlock generation

(1) Mutually exclusive conditions

The process uses the resource as an exclusive, that is, for a period of time, a resource is occupied by only one process.

(2) Request and hold conditions

When a process is blocked by requesting a resource, it remains in place for the resources that have been obtained.

(3) Conditions of non-deprivation

The resources that the process has obtained cannot be stripped until it is exhausted and can only be released by itself when it is exhausted.

(4) Loop wait condition

Each process consists of a closed ring chain, each of which waits for the resources occupied by the next process

Deadlock prevention

Resource One-time allocation: (Breach request and hold condition)

Deprivation of resources: destruction of inalienable conditions)

The method of orderly allocation of resources: (destruction of cyclic waiting conditions)

Deadlock avoidance

Several strategies for preventing deadlocks can seriously damage system performance. Therefore, when the deadlock is avoided, a weaker limit is applied to achieve satisfactory system performance.

Because the process is allowed to request resources dynamically, in a policy that avoids deadlocks. Therefore, the system pre-calculates the security of resource allocation before allocating resources. If this allocation does not cause the system to enter an unsafe state, the resource is assigned to the process; otherwise, the process waits. One of the most representative of the avoidance deadlock algorithm is the banker algorithm.

Banker algorithm

To ensure the safety of the funds, the banker rules:

(1) When a customer's maximum demand for funds does not exceed the bank's existing funds, it can accept the customer;

(2) the customer may loan in installments, but the total amount of the loan cannot exceed the maximum demand

(3) when the banker's existing funds do not meet the customer's remaining loan amount, the loan to the customer may be deferred, but the customer can always get the loan in a limited time.

(4) When the customer receives all the necessary funds, they will be able to return all the funds in a limited time.

The problem of dining philosophers

Five philosophers in a round table dining, everyone must pick up two forks to eat;

The solution to the problem of dining philosophers:

(1) Waiter solution: The waiter as a manager, the philosopher in the fork before the need to obtain the waiter's consent;

(2) a maximum of 4 philosophers;

(3) only when a philosopher on both sides of chopsticks are available, he is allowed to take chopsticks;

(4) Numbering all philosophers, the philosopher of the odd number must first take the chopsticks on the left, and the even number of philosophers;

Signal Volume

The semaphore and P, V primitives are proposed by Dijkstra (Dijkstra), the three major contributions of Dijkstra: goto harmful, PV primitive, Digestala shortest path algorithm;

Signal magnitude value meaning

s>0: S Indicates the number of available resources

s=0: Indicates no resources available, no wait process

s<0: | S| indicates the number of processes waiting in the queue

PV operation

Semaphore definition typedef struct{   int value;   struct Process_control_block *list;} Semaphore

P Primitive//p (semaphore *s) Wait (semaphore *s) {    --s->value;    if (S->value < 0)    {        //sets the current process to a blocking state        //Inserts the current process's PCB into the appropriate blocking queue S->list        block (s->list);}    }

V Primitives//v (semaphore *s) signal (semaphore *s) {    + + s->value;    if (s->value <= 0)  //indicates that there is a process    waiting in the blocking state {        //wake-up blocking queue s->list, set it to ready state;        Insert it into the ready queue;        Wakeup (s->list);    }}

Linux IPC Practice (1)--Overview