ReaderWriterLockSlim.EnterUpgradeableReadLock()始终是死锁？

Question

我非常熟悉,ReaderWriterLockSlim但我EnterUpgradeableReadLock()最近在一个类中尝试实现...不久之后我意识到当2个或更多线程运行代码时,这几乎肯定是一个保证死锁:

Thread A --> enter upgradeable read lock
Thread B --> enter upgradeable read lock
Thread A --> tries to enter write lock, blocks for B to leave read
Thread B --> tries to enter write lock, blocks for A to leave read
Thread A --> waiting for B to exit read lock
Thread B --> waiting for A to exit read lock

我在这里错过了什么？

编辑

添加了我的场景的代码示例.该Run()方法将由两个或多个线程同时调用.

public class Deadlocker
{
    private readonly ReaderWriterLockSlim _lock = new ReaderWriterLockSlim(LockRecursionPolicy.SupportsRecursion);

    public void Run()
    {
        _lock.EnterUpgradeableReadLock();
        try
        {
            _lock.EnterWriteLock();
            try
            {
                // Do something
            }
            finally
            {
                _lock.ExitWriteLock();
            }
        }
        finally
        {
            _lock.ExitUpgradeableReadLock();
        }
    }
}

Answer 1

OP之后很长一段时间,但我不同意目前接受的答案.

声明Thread B --> enter upgradeable read lock 不正确.来自文档

任何时候只有一个线程可以处于可升级模式

并回应您的意见:它旨在用于读写模式的非常不同的用法.

TL; DR.可升级模式很有用:

• 如果作者必须在写入之前检查共享资源,并且(可选)需要避免与其他作者的竞争条件;
• 并且它不应该阻止读者,直到它100%确定它必须写入共享资源;
• 并且很可能一个编写者决定在执行检查后不应该写入共享资源.

或者,在伪代码中,这里:

// no other writers or upgradeables allowed in here => no race conditions
EnterUpgradeableLock(); 
if (isWriteRequired()) { EnterWriteLock(); DoWrite(); ExitWriteLock(); } 
ExitUpgradeableLock();

给予"更好的表现" ^÷比这:

EnterWriteLock(); if (isWriteRequired()) { DoWrite(); } ExitWriteLock();

如果独占锁定部分由于使用SpinLock而需要很长时间,则应小心使用.

类似的锁构造

可升级锁与SQL服务器SIX锁(与Intent共享以获得exclusive)惊人相似^†.

• 要重写上面的语句在这些方面,一个可升级的锁说,"一个作家有意写的资源,但希望与其他读者分享它,而它[双]检查的条件,看它是否应完全锁定并执行写" ^‡.

如果没有Intent锁,您必须在eXclusive锁中执行"我应该进行此更改"检查,这会损害并发性.

为什么你不能共享可升级？

如果可升级锁可与其他可升级锁共享,则可能与其他可升级锁所有者具有竞争条件.因此,您需要在写锁定内部进行一次检查,从而消除了检查的好处,而不会阻止其他读取操作.

例

如果我们把所有的锁等待/进入/退出事件的顺序,以及锁定为平行内的工作,那么我们就可以写"大理石"形式的情况下(e进入; w等待; x退出; cr检查资源; mr变异资源; R共享/读取; U意图/可升级; WeXclusive/Write):

1--eU--cr--wW----eW--mr--xWxU--------------
2------eR----xR----------------eR--xR------
3--------eR----xR--------------------------
4----wU----------------------eU--cr--xU----

用语言:T1进入Upgradeable/Intent锁.T4等待Upgradeable/Intent锁定.T2和T3输入读锁.T1同时检查资源,赢得比赛并等待eXclusive/Write锁定.T2和T3退出锁.T1进入eXclusive/Write锁定并进行更改.T4进入可升级/意图锁定,不需要进行更改并退出,而不阻止T2,同时执行另一次读取.

在8个要点......

可升级锁是:

1. 任何作家使用;
2. 谁可能先检查然后决定不以任何理由执行写入(丢失竞争条件,或以Getsert模式);
3. 谁不应该阻止读者,直到它知道它必须执行写;
4. 因此它将取出一个独占锁并这样做.

如果下列之一适用(包括但不限于),则不需要升级:

5. 读取器和writelock-check-nowrite-exit写入器之间的争用率几乎为零(写入条件检查超快) - 即可升级的构造对读取器吞吐量没有帮助;

6. 写入锁写入一次的写入器的概率是〜1,因为:

   • ReadLock-Check-WriteLock-DoubleCheck 是如此之快,它只会导致每万亿次写入失败者;
   • 所有变化都是独一无二的(所有变化都必须发生,种族不可能存在); 要么
   • "最后的改变胜利"(所有改变仍然必须发生,即使它们不是唯一的)

如果a lock(...){...}更合适,也不需要它,即:

7. 重叠读取和/或写入窗口的概率很低(锁定可以同样防止非常罕见的事件,因为保护极有可能的事件,更不用说简单的内存屏障要求)
8. 您所有的锁定都是可升级或写入,永远不会读取('duh')

^÷ "性能"由您来定义

^† 如果您将锁定对象视为表,并将受保护资源视为层次结构中较低的资源,则此类比近似成立

^‡ 读取锁定中的初始检查是可选的,可升级锁定内的检查是强制性的,因此可以单个或双重检查模式使用.