Concurrency control driven by Linux devices

one, concurrency and state

Concurrency: Multi-CPU or single CPU multi-process multithreading simultaneous execution

State: Simultaneous access to shared resources

Concurrency occurs in the following 4 scenarios:

(1) Multi-CPU

(2) Single CPU multi-process multithreading

(3) Single CPU process and interrupt

(4) Single CPU interrupt and interrupt

second, process scheduling

1. Process scheduling is scheduled according to the time slice, process A's time slice ran out, will call process B

2. Can be preempted and not preempted

Preemption: Interrupts the current process (user state or kernel state) and executes other processes.

User-State preemption moment:

(1) System call back to user state

(2) Interrupt, interrupt the user state process, and then interrupt the return time

Kernel-State preemption:

[1] The interrupt returns to the kernel state, and the Linux operating system checks to see if it can preempt
[2] kernel-state process blocked or itself called the schedule () function
[3] Release lock (spin_unlock: Will be Preempt_count-)

The kernel can be divided into: preemptive and non-preemptive

third, close the interruption

Summarize:

Concurrency in the above 4:2,3,4 Three cases can be guaranteed to be out of competition by shutting down interrupts.

four, Spin lock

Single CPU platform: Spin lock function just off preemption
Multi-CPU platform: Kernel space off preemption + flag (V)

Use spin lock purpose?
Prevent multiple performers from accessing shared resources at the same time

Process and Process->ok
Processes and interrupts--processes that use shared resources also need to shut down corresponding interrupts
Interrupts and interrupts
A interrupt handler function uses a spin lock, B interrupts high priority, preemption a interrupts, and also uses spin locks, what happens when?
At this point, the B process will spin down.

How do I avoid concurrency between interrupts?
When the interrupt handler is executed, the IRQ exception is closed (equivalent to all interrupts being closed)

Five, the signal volume

Feature: The process will hibernate when the process cannot get the semaphore

1. Define the semaphore

struct semaphore sem;

2. Initialize the semaphore

Sema_init (struct semaphore *sem,int value);

3. Get the semaphore

void down (struct semaphore *sem);//Cannot get, process enters non-interruptible waiting state
int Down_interrupt (STRCT sempaphore *sem);//cannot be obtained, process enters interruptible wait

4. Releasing the semaphore

void up (struct semaphore *sem);//wake up all processes waiting for the current semaphore

Note: semaphores can no longer be used in interrupt handling functions

six, mutual exclusion lock

(1) The semaphore can already be mutually exclusive, why use mutex lock?
The signal volume is mainly used to realize the p,v operation, the mutual exclusion efficiency is lower than the mutex lock.

(2) What is the difference between a mutual exclusion lock and a spin lock?
[1] The mutex cannot acquire a lock when the process is blocked, and the spin lock does not, it will process spin
[2] Spin lock off preemption, mutex not off preemption

(3) using mutex lock
[1] Defining Mutual exclusion locks
struct Mutex_lock mlock;
[2] Initialization
Mutex_init (struct mutex_lock *lock);

[3] Acquiring the lock
Mutex_lock (struct mutex_lock *lock);

[4] Release lock
Mutex_unlock (struct mutex_lock *lock);

vii. Atomic Manipulation

Concurrency control driven by Linux devices