问题描述
要掌握某些技术，您必须知道它是如何在更低的抽象级别上实现的.在多线程编程的情况下，最好了解同步原语.
这是一个问题，如何在 .NET 中实现 Lock (Monitor)?
For mastering of some technology you have to know how it's made at one abstraction level lower. In case of multithreading programming, it will be good to know about synchronization primitives.
Here is the question, how implemented Lock (Monitor) in .NET?
我对这些方面很感兴趣:
- 它是否使用操作系统对象?;
- 它需要用户模式还是内核模式?;
- 等待锁的线程的开销是多少?;
- 在什么情况下，等待锁的线程队列可能会被违反?
I'm intrested in such points:
- does it utilize OS objects?;
- does it require user mode or kernel mode?;
- what is overhead for threads that are waiting for lock?;
- in what cases threads queue that awaiting for the lock could be violated?.
更新:
如果多个线程争用锁，它们将在就绪队列"中排队，并按照先到先得的原则授予锁.注意:Windows 和 CLR 行为中的细微差别意味着队列的公平性有时会被违反."[C# 4.0 in a Nutshell, Joseph Albahari] 所以这就是我在最后一个关于违反队列"的问题中要问的问题.
Updated:
"If more than one thread contends the lock, they are queued on a "ready queue" and granted the lock on a first-come, first-served basis. Note: Nuances in the behavior of Windows and the CLR mean that the fairness of the queue can sometimes be violated." [C# 4.0 in a Nutshell, Joseph Albahari] So this is what I'm asking about in last question concerning 'violated queue'.
推荐答案
经过一些调查，我找到了问题的答案.一般来说，CodeInChaos 和 Henk Holterman 是对的，但这里有一些细节.
After some investigations I've found out answers to my questions. In general CodeInChaos and Henk Holterman were right, but here is some details.
当线程首先开始与其他线程竞争锁时，它会旋转等待循环一段时间以尝试获取锁.所有这些操作都在用户模式中执行.然后，如果没有成功创建 OS 内核对象 Event，线程将切换到 kernel-mode 并等待来自此 Event 的信号.
When thread start to contends for a lock with other threads firstly it it does spin-wait loop for a while trying to obtain lock. All this actions performs in user-mode. Then if no success OS kernel object Event creates, thread is switched to the kernel-mode and waits for signal from this Event.
所以回答我的问题是:
1. 在更好的情况下不，但在更糟糕的情况下是(Event 对象在需要时懒惰地创建)；
2. 一般在用户模式下工作，但如果线程争夺锁的时间过长，线程可以切换到内核模式(通过Win API非托管函数调用)；
3. 从用户模式切换到内核模式的开销(约 1000 个 CPU 周期)；
4. 微软声称它是像 FIFO 一样的诚实"算法，但它不保证这一点.(例如，如果来自等待队列"的线程将被挂起，它会在恢复时移动到队列的末尾.)
So answer to my questions are:
1. In better case no, but in worse yes (Event object lazily creates if required);
2. In general it works in user-mode but if threads compete for a lock too long, thread could be switched to kernel-mode (via Win API unmanaged function call);
3. Overhead for switch from user-mode to kernel-mode (~1000 CPU cycles);
4. Microsoft claim that it is "honest" algorithm like FIFO but it doesn't guarantee this. (E.g. If thread from 'waiting queue' will be suspended it moves to the end of queue when it would be resumed.)
这篇关于.NET 中的锁定(监视器)内部实现的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持编程学习网！