“自旋锁”到底是什么?
我总是想知道它们是什么:每次我听到它们时,未来派飞轮式设备的图像都会在我的脑海中跳舞(滚动?)...
它们是什么?
I always wondered what they are: every time I hear about them, images of futuristic flywheel-like devices go dancing (rolling?) through my mind...
What are they?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(12)
当您使用常规锁(互斥锁、临界区等)时,操作系统会将您的线程置于 WAIT 状态并且 通过在同一核心上调度其他线程来抢占它。如果等待时间非常短,这会造成性能损失,因为您的线程现在必须等待抢占才能再次接收 CPU 时间。
此外,内核对象并非在内核的每个状态下都可用,例如在中断处理程序中或分页不可用时等。
自旋锁不会导致抢占,而是在循环中等待(“自旋”),直到另一个内核释放该内核对象。锁。这可以防止线程丢失其量子并在获得锁定后立即继续释放。自旋锁的简单机制允许内核在几乎任何状态下使用它。
这就是为什么在单核机器上,自旋锁只是“禁用中断”或“引发 IRQL”,完全阻止线程调度。
自旋锁最终允许内核避免“大内核锁”(内核进入内核时获取并在退出时释放的锁)并对内核原语进行粒度锁定,从而在多核机器上实现更好的多处理,从而获得更好的性能。
编辑:出现了一个问题:“这是否意味着我应该尽可能使用自旋锁?”我会尝试回答这个问题:
正如我所提到的,自旋锁仅在预期等待时间短于量子(读:毫秒)并且抢占没有多大意义的地方有用(例如,内核对象不可用) 。
如果等待时间未知,或者处于用户模式,自旋锁效率不高。在检查自旋锁是否可用时,您会在等待核心上消耗 100% 的 CPU 时间。您可以阻止其他线程在该核心上运行,直到您的时间片到期。这种情况仅适用于内核级别的短突发,并且不太可能是用户模式应用程序的选项。
这是一个关于 SO 解决的问题:自旋锁,它们有多有用?
When you use regular locks (mutexes, critical sections etc), operating system puts your thread in the WAIT state and preempts it by scheduling other threads on the same core. This has a performance penalty if the wait time is really short, because your thread now has to wait for a preemption to receive CPU time again.
Besides, kernel objects are not available in every state of the kernel, such as in an interrupt handler or when paging is not available etc.
Spinlocks don't cause preemption but wait in a loop ("spin") till the other core releases the lock. This prevents the thread from losing its quantum and continue as soon as the lock gets released. The simple mechanism of spinlocks allows a kernel to utilize it in almost any state.
That's why on a single core machine a spinlock is simply a "disable interrupts" or "raise IRQL" which prevents thread scheduling completely.
Spinlocks ultimately allow kernels to avoid "Big Kernel Lock"s (a lock acquired when core enters kernel and released at the exit) and have granular locking over kernel primitives, causing better multi-processing on multi-core machines thus better performance.
EDIT: A question came up: "Does that mean I should use spinlocks wherever possible?" and I'll try to answer it:
As I mentioned, Spinlocks are only useful in places where anticipated waiting time is shorter than a quantum (read: milliseconds) and preemption doesn't make much sense (e.g. kernel objects aren't available).
If waiting time is unknown, or if you're in user mode Spinlocks aren't efficient. You consume 100% CPU time on the waiting core while checking if a spinlock is available. You prevent other threads from running on that core till your quantum expires. This scenario is only feasible for short bursts at kernel level and unlikely an option for a user-mode application.
Here is a question on SO addressing that: Spinlocks, How Useful Are They?
假设资源受锁保护,想要访问该资源的线程需要首先获取锁。如果锁不可用,线程可能会重复检查锁是否已被释放。在此期间,线程忙于等待、检查锁、使用 CPU,但不做任何有用的工作。这种锁称为自旋锁。
Say a resource is protected by a lock ,a thread that wants access to the resource needs to acquire the lock first. If the lock is not available, the thread might repeatedly check if the lock has been freed. During this time the thread busy waits, checking for the lock, using CPU, but not doing any useful work. Such a lock is termed as a spin lock.
这基本上是一个循环,一直持续到满足某个条件为止:
It is pertty much a loop that keeps going till a certain condition is met:
这是一种忙等待的锁。
它被认为是一种反模式,除了非常低的情况之外。级驱动程序编程(调用“适当的”等待函数可能比简单地忙锁定几个周期具有更多的开销)。
例如,请参阅 Linux 内核中的自旋锁。
It's a type of lock that does busy waiting
It's considered an anti-pattern, except for very low-level driver programming (where it can happen that calling a "proper" waiting function has more overhead than simply busy locking for a few cycles).
See for example Spinlocks in Linux kernel.
自旋锁是线程等待锁可用的锁。当在某个小时间段内存在获取内核对象的范围时,这通常用于避免获取内核对象的开销。
前任:
SpinLocks are the ones in which thread waits till the lock is available. This will normally be used to avoid overhead of obtaining the kernel objects when there is a scope of acquiring the kernel object within some small time period.
Ex:
当您认为进入繁忙的等待循环并池化资源而不是在资源被锁定时阻塞更便宜时,您可能会想要使用自旋锁。
You would want to use a spinlock when you think it is cheaper to enter a busy waiting loop and pool a resource instead of blocking when the resource is locked.
这是一个循环,直到满足条件为止。
It's a loop that spins around until a condition is met.
简而言之,自旋锁采用原子比较和交换(CAS)或类似测试和设置的指令来实现无锁、无等待的线程安全习惯。这种结构在多核机器中可以很好地扩展。
In nutshell, spinlock employs atomic compare and swap (CAS) or test-and-set like instructions to implement lock free, wait free thread safe idiom. Such structures scale well in multi-core machines.
嗯,是的 - 自旋锁(与传统的关键部分等相比)的要点是它们在某些情况下(多核系统..)提供更好的性能,因为它们不会立即产生线程的其余量子。
Well, yes - the point of spin locks (vs a traditional critical sections, etc) is that they offer better performance under some circumstances (multicore systems..), because they don't immediately yield the rest of the thread's quantum.
自旋锁是一种锁,它是非阻塞的并且可以阻塞。无法入睡。任何想要获取任何共享或关键资源的自旋锁的线程都会不断自旋,浪费 CPU 处理周期,直到它获取指定资源的锁。一旦获得自旋锁,它就会尝试完成其量程中的工作,然后分别释放资源。自旋锁是优先级最高的锁类型,简单地说,它是非抢占式的一类锁。
Spinlock, is a type of lock, which is non-block able & non-sleep-able. Any thread which want to acquire a spinlock for any shared or critical resource will continuously spin, wasting the CPU processing cycle till it acquire the lock for the specified resource. Once spinlock is acquired, it try to complete the work in its quantum and then release the resource respectively. Spinlock is the highest priority type of lock, simply can say, it is non-preemptive kind of lock.
当一个线程已获取锁并处于其临界区时,尝试获取锁的所有其他线程都处于循环中,其中线程定期检查锁是否可用。因此,它会自旋以获取锁,并浪费了本来可以被其他线程高效使用的 CPU 周期。
这是单CPU机器上的一个主要问题。自旋锁也称为忙等待,因为线程“忙”等待锁。
来源
While one thread has acquired the lock and is in its critical section, all other threads attempting to acquire the lock are in a loop where the thread periodically checks whether the lock is available. Thus, it spins for the lock and wastes CPU cycles that could have been used by some other threads productively.
This is a major problem in a single CPU machine. Spinlock is also known as busy waiting as the thread is "busy" waiting for the lock.
Source