Comparison between signal lights and spin locks.

SEM isSleep lock.If a task tries to obtain an held semaphore, the semaphore will push it into the waiting queue and then sleep it. In this case, the processor is free to execute other code. When the process holding the semaphore releases the semaphore, a task in the waiting queue will be awakened to obtain the semaphore. Semaphores are generally in the context of processes. They are used to prevent multiple processes from simultaneously accessing a shared resource (critical section ).

Spin_lock is calledSpin lock. Is when you try to request an already held spin lock. this task will keep running-Rotating-waiting until the lock is re-available (It will continue this way, without releasing the CPU, it can only be used to lock for a short time ). it is used to prevent multiple CPUs from simultaneously accessing a shared resource (critical section ). it is generally used in the interrupt context because the interrupt context cannot be interrupted or scheduled.

Semaphores

Recommended locking method

The spin lock is preferred for low-cost locking.

Short-term locks give priority to spin locks

Semaphores are preferentially used for long-term locking.

Apply spin lock to intercept context locking

Holding locks requires sleep and scheduling to use semaphores.

SEM between processes. The SEM between threads is similar to that in the kernel.

The SEM between processes and the SEM function between threads are the same. It is only the SEM of threads. It is in the same process space and its initialization is more convenient to use.

The SEM between processes is part of inter-process communication. It is completed by using system calls such as semget and semop.

The SEM in the kernel is locked, which means that the called process occupies this SEM. Other processes can only perform sleep queues, which is basically consistent with the SEM between processes.

Differences	Spin_lock	Semaphore
Protected object	Code segment	One device (not required ), A variable, Code segment
Protected area can be preemptible	No	Yes.
Allows hibernation in protected objects (CODE)	No	Yes. But it is better not.
Can protected area be interrupted?	Yes. This will easily lead to deadlocks. It is best to use this lock after the interruption is disabled. Because it is possible that the interrupt processing routine also needs to get the same lock.	Yes.
Other functions		Synchronization can be completed, with the ability to convey information.
Process performance when the attempt to occupy the lock fails	Do not open the CPU and spin it yourself.	Enter a waiting queue.
After the lock is released, how does the Kernel Handle other processes waiting?	A cpu (not a process) first finds that the lock has been released, and then it gets the lock.	Select one from the waiting queue to occupy this SEM.
User Requirements for the kernel	It takes a short time to execute protected code, which is atomic, Active sleep is not allowed. You cannot call kernel functions that can be sleep.
Risks	Deadlock
	The holder of the lock is not allowed to request the same lock twice.	The holder of the lock is not allowed to request the same lock twice.

Semaphores can be synchronized between producers and consumers.

When the down and up of SEM appear in the opposite functions (Read and Write Functions), this is actually a message. Indicates whether data is readable.

Read_somthing ()

{

Down (device) occupies this device. No one else uses all operations on this device (function)

If (with data)

{

Read it.

()

}

Else

{

Up (device)

Down (SEM with data) SEM = 1 indicates there is data, 0 indicates no data.

}

}

Write_somthing ()

{

Down (device) occupies this device. No one else uses all operations on this device (function)

If (with data)

{

Do not write.

Up (device)

Return

}

Else

{

Write Data

Up (SEM with data) SEM = 1 indicates there is data, 0 indicates no data.

Up (device)

Return;

}

}