Semaphores and spin locks (1): concurrency and Competition

1. concept:

• A large number of concurrent accesses exist in the operating system, which may lead to the possibility of a race state. A race State is usually generated by sharing resources.
• When two execution threads access the same data structure (or hardware resources), this possibility will always exist.
• Therefore, the primary principle is to avoid this situation during the design process.
• However, in most cases, such sharing is necessary, including hardware resources, global variables, and multi-direction pointer transfer.

2. Management:
The hard rules for resource sharing are:

• When a resource is shared outside a single execution thread, the other thread may observe the resource differently. Therefore, you must explicitly manage access to the resource.
• When a resource is available, it must prepare requests for its resources until there is no reference to the resource. (for example, an opened user space file ). this is usually handled by reference counting.

3. Example:
Process A and process B allocate memory for a device at the same time.
When process a has allocated memory to the device, the data seen from process B is inconsistent with process A, that is, process B does not know that process a has allocated memory for the shared device, so it will perform its own allocation and overwrite process. this apparently causes memory leakage and causes more problems. in this case, process a and process B must be controlled to access the shared device. this requires that the shared data in the shared device be used to execute all processes (such as A, B, C ...) and protect the shared data.
This protection can be implemented through two mechanisms:

• Semaphores
• Spin lock