c# - 在任何情况下，在 ReaderWriterLockSlim 上调用 EnterWriteLock 应该进入读锁吗？

Question

我有一个看似非常简单的案例，我在 .NET Framework 3.5 版本中使用 System.Threading.ReaderWriterLockSlim。我首先声明一个，如下所示:

Lock Declaration http://odeh.temp.s3.amazonaws.com/lock_declaration.bmp

我在获取锁之前放置了一个断点并拍摄了一张屏幕截图，这样您就可以看到(在监 window 口中)当前没有锁:

pre lock acquisition http://odeh.temp.s3.amazonaws.com/prelock.bmp

然后，在调用 EnterWriteLock 之后，如您所见，我持有一个 Read Lock。

post lock acquisition http://odeh.temp.s3.amazonaws.com/postlock.bmp

这似乎是真正出乎意料的行为，我无法在任何地方找到它的记录。有谁知道为什么会这样？在我的代码的其他地方(之前)，这行完全相同的代码正确地获得了写锁。然而，在多个系统中，它始终在调用堆栈的这个位置获得读锁。希望我已经说清楚了，感谢您花时间看这个。

--- 编辑---

对于那些提到断言的人……这让我更加困惑:

post assert http://odeh.temp.s3.amazonaws.com/assert.bmp

我真的不能说它是如何通过这个断言的，除了 Watch Window 和 Immediate 窗口可能是错误的(也许该值存储在本地线程中，正如另一张海报所提到的)。这似乎是 volatile 变量和要建立的 Happens Before 关系的明显案例。无论哪种方式，几行之后都有断言写锁但没有写锁的代码。我在整个程序中唯一释放此锁的代码行上设置了一个断点，并且它在此处显示的获取之后没有被调用，所以这一定意味着它从未真正被获取...对吧？

Answer 1

这可能是调试器的副作用。 ReaderWriterLockSlim 类对当前线程 ID (Thread.ManagedThreadId) 非常敏感。我无法说明调试器将始终使用当前事件线程来评估监视表达式这一事实。通常会这样，但可能会有不同的行为，例如，如果您通过硬中断进入调试器。

首先要相信代码的作用，您的 Debug.Assert 证明了这一点。