About Spin Locks

[bluecrest]

Spin locks
In multiprocessor systems, semaphores are not always the best solution to the synchronization problems. Some kernel data structures should be protected from being concurrently accessed by kernel control paths that run on different CPUs. In this case, if the time required to update the data structure is short, a semaphore could be very inefficient. To check a semaphore, the kernel must insert a process in the semaphore list and then suspend it. Because both operations are relatively expensive, in the time it takes to complete them, the other kernel control path could have already released the semaphore.

In these cases, multiprocessor operating systems use spin locks . A spin lock is very similar to a semaphore, but it has no process list; when a process finds the lock closed by another process, it "spins" around repeatedly, executing a tight instruction loop until the lock becomes open.

Of course, spin locks are useless in a uniprocessor environment. When a kernel control path tries to access a locked data structure, it starts an endless loop. Therefore, the kernel control path that is updating the protected data structure would not have a chance to continue the execution and release the spin lock. The final result would be that the system hangs

上面红色的那部分情况我认为在multiprocessor中也存在的，因为multiprocessor不代表kernel control paths that run on different CPUs。我这样的理解对吗？

[nehc]

问题是什么呢 ？ 懒得看 E 文

[nevil]

是的,在多处理器下使用spin_lock同样要注意, 临界区代码不能休眠 因为一个进程拥有spin_lock后休眠让出处理器,另一个想要获得spin_lock的进程会自旋很长时间来等待获得这个锁, 最坏的情况,整个系统会死锁

[bluecrest]

为什么这些kernel data structures不用考虑单cpu的情况？ 这是一种什么样的情况呢？

[bluecrest]

我对于红色这段话的理解是这样的， 如果是在单cpu上面，当一个线程获得spin_lock后，被调度器切换到另一个优先级比他高的线程的想获得spin_lock的线程，那么系统可能会hang住。 但是如果在多cpu上面，我觉得也会发生这样的情况。但是understanding linux kernel 这本书关于 Spin locks 的介绍，他只强调了 spin locks are useless in a uniprocessor environment。 说明spin locks multiprocessor上面不会hang住系统。 根据我前面的想法应该也会，不知何故书只强调了uniprocessor。

[deep_pro]

仔细看原文 Some kernel data structures should be protected from being concurrently accessed by kernel control paths that run on different CPUs. 所以你1楼的疑问建立在错误的理解上。 multiprocessor代表kernel control paths that run on different CPUs。

[deep_pro]

单核cpu，又分可抢占和不可抢占2种情况。 单核+不可抢占内核，不同的进程上下文之间访问同一资源，不需要任何保护 单核+不可抢占内核，进程上下文和中断上下文共享一个资源，只要禁用中断即可实现保护作用 单核+可抢占内核，不同的进程上下文之间访问同一资源，只要临时禁止抢占即可 单核+可抢占内核，进程上下文和中断上下文共享一个资源，需要禁用中断+临时禁止抢占 单核下，即使是最复杂的情况，也只要禁用中断+临时禁止抢占即可，完全不需要神马原子操作来操作自旋锁的数据结构。 所以单核下的自旋锁（spin_lock_irqsave），根本不需要用原子操作去操作那个锁的数据结构（kernel data structures）。

[bluecrest]

Of course, spin locks are useless in a uniprocessor environment. When a kernel control path tries to access a locked data structure, it starts an endless loop. Therefore, the kernel control path that is updating the protected data structure would not have a chance to continue the execution and release the spin lock. The final result would be that the system hangs spin lock在uniprocessro上会导致系统hangs主，那么在multiprocessor上面为什么就不会hangs主呢?