Lock mechanism in kernel __ kernel

Kernel lock

Multi-core processors, there will be several processes in the kernel state, and in the kernel state, the process can access all kernel data, so to protect the shared data, that is, mutual exclusion

Classification (1) Atomic Operation

atomic_t data type, Atomic_inc (atomic_t *v) will v plus 1
Atomic operations are less efficient than normal operations, and are therefore used only when necessary and cannot be mixed with normal operations
In the case of a single core processor, atomic operations are the same as normal operations (2) semaphores and mutexes

struct semaphore data types, down (struct semaphore * sem) and up (struct semaphore * sem) are occupied and released
struct mutex data types, mutex_lock (struct mutex *lock) and mutex_unlock (struct mutex *lock) are lock and unlock
Competing semaphores and mutexes require processes to sleep and wake up at a high cost, so they are not suitable for short-term code protection, and are useful for protecting a longer critical area, and the kernel is increasingly inclined to use mutexes. (3) reader/writer Semaphore

A Rwsem allows a writer or an infinite number of readers to have the semaphore, and the writer has a higher priority; When a writer enters a critical section, the reader is not allowed access until all the writers have finished writing. If there is a large number of writers competing for the semaphore, this implementation can cause the reader to "starve to death".
Therefore, it is best to use Rwsem when there is little need for write access and the writer will only have the semaphore for a short time.
struct Rw_semaphore;
void Init_rwsem (struct rw_semaphore *sem);

void Down_read (struct rw_semaphore *sem);
void Down_read_trylock (struct rw_semaphore *sem);
void Up_read (struct rw_semaphore *sem);

void Down_write (struct rw_semaphore *sem);
void Down_write_trylock (struct rw_semaphore *sem);
void Up_write (struct rw_semaphore *sem); (4) Completion

A pattern that is common in kernel programming, where an activity is performed outside the current thread, and then waits for the end of the activity. This activity may be to create a new kernel thread or a new user-space process, a request to an existing process, or a type of hardware operation, and so on.
In this case, we can use the semaphore to synchronize the two tasks, as shown in the following example:
struct semaphore sem;
Sema_init (&sem,0);//locked
Start_external_task (&sem);
Down (&SEM);
because the semaphore's up and down operations can be performed separately in two threads, the Up (&sem) is invoked after the task completes in Start_external_task. This will awaken the waiting source thread. (Note: For this type of signal synchronization, the application layer can also be handled in a similar manner.) However, in the application-layer thread synchronization using the conditional variable, you can encapsulate the condition variable into the form of SEM, it will be used in a similar way.
using semaphores in the kernel can achieve synchronization, but there is another mechanism for better performance, which is the completion interface.
Declare_completion (done);
struct completion done;
Init_completion (&done);
Wait:
void wait_for_completion (struct completion *c);
Wake:
void Complete (struct completion *c);
void Complete_all (struct completion *c); (5) spin lock

The process that waits for the unlock will repeatedly check whether the lock is released without going to sleep (busy waiting), so it is often used to protect a piece of code in the short term. At the same time, the process of holding a spin lock does not allow sleep, or it can cause deadlocks-because sleep may cause the process of holding locks to be scheduled again, and then reapply for the locks that they have held.
Spin locks were originally designed to be used on multiprocessor systems, and single processor workstations behave like SMP when running a preemptive kernel, given the concurrency problem. If a non preemptive single processor goes into the spin state of a lock, it spins forever, since no other thread can get the CPU to release the lock. Therefore, a spin lock on a non preemptive single-processor system is optimized to do nothing, but a routine that changes the status of the IRQ mask is an exception.
The core rule of using spin locks is that any code that has a spin lock must be atomic, it cannot hibernate, and it cannot give up the processor for any reason, except to interrupt the service (in some cases, the processor cannot be discarded). Avoiding hibernation When you have a spin lock is sometimes hard to do, and hibernation can happen in many places that you can't anticipate, and when we write code that needs to be executed under a spin lock, we have to be aware of each function that is called.
Api:
spinlock_t my_lock = spin_lock_unlocked;
void Spin_lock_init (spinlock_t *lock);

void Spin_lock (spinlock_t *lock);
void Spin_unlock (spinlock_t *lock);

Because Spinlock can be used in interrupt routines, there are some operational function APIs associated with interrupts to prevent deadlocks:
void Spin_lock_irqsave (spinlock_t *lock, unsigned long flags);
void Spin_lock_irq (spinlock_t *lock);
void Spin_lock_irq_bh (spinlock_t *lock);

void Spin_unlock_irqrestore (spinlock_t *lock, unsigned long flags);
void Spin_unlock_irq (spinlock_t *lock);
void Spin_unlock_irq_bh (spinlock_t *lock);

void Spin_trylock (spinlock_t *lock);
void Spin_trylock_bh (spinlock_t *lock);

The Irqsave version prohibits the current CPU from interrupting until the lock is acquired, and the interrupt state is saved in flags. The IRQ version disables the current CPU interruption before acquiring the lock, and does not save the state. The BH version prohibits the software from interrupting until the lock is acquired, but it will cause the hardware to break open. The BH version is mainly used in the hardware interrupt is not accessed, software interrupt access to the lock. (6) reader/writer spin lock

Similar to the reader/writer semaphore, the kernel also provides the reader/writer form of the spin lock. This lock allows any number of readers to enter the critical section at the same time, but the writer must be mutually exclusive access.
rwlock_t my_rwlock = rw_lock_unlocked;
rwlock_t My_rwlock;
Rwlock_init (&rwlock);

... API skips the difference between mutexes and semaphores?

The

(1) Mutex is used for mutual exclusion of threads, semaphores are used primarily for synchronization of threads
This is the fundamental difference between mutexes and semaphores, that is, the difference between mutexes and synchronizations
Mutex: A resource that allows only one visitor to access it at the same time, is unique and exclusive. But mutexes cannot limit the order in which visitors access the resource, that is, the access is unordered
synchronization: It means that on a mutually exclusive basis (most of the cases), the visitor's ordered access to the resource is achieved through other mechanisms. In most cases, synchronization has been mutually exclusive, especially if all writes to the resource must be mutually exclusive. In a few cases, you can allow more than one visitor to access the resource at the same time
(2) The mutex value can only be 0/1, and the semaphore value may be a non-negative integer
that is, a mutex is only available for exclusive access to one resource, and it cannot implement multiple threads mutex issues. Semaphores can achieve multiple threads of mutual exclusion and synchronization of similar resources. When the signal quantity is a single value signal, you can also complete a mutually exclusive access to a resource
(3) the lock and unlock of the mutex must be used separately by the same thread, the semaphore can be obtained by one, and the other thread is released, which is why it can be used for synchronization.