代码之家  ›  专栏  ›  技术社区  ›  Neil Barnwell

readerWriterLockSlim.EnterUpgradeableReadLock()是否与monitor.enter()基本相同?

  •  3
  • Neil Barnwell  · 技术社区  · 14 年前

    因此,我遇到了这样一种情况:我可能有很多次读操作,而只是偶尔对多个线程之间共享的资源进行写操作。

    很久以前我读到 ReaderWriterLock ,并已阅读有关 ReaderWriterGate 它试图缓解特朗普读到的许多文章损害业绩的问题。但是,现在我意识到 ReaderWriterLockSlim

    从文档中,我相信在任何时候都只能有一个线程处于“可升级模式”。在这种情况下,我唯一的办法是 EnterUpgradeableReadLock() (这很适合我的场景)那么坚持到底有什么不同 lock(){} ?

    以下是摘录:

    试图进入的线 可升级模式块(如果有) 已经是处于可升级模式的线程, 如果有线程等待进入 写入模式,或者如果有一个 线程处于写入模式。

    或者,递归策略对此有什么不同吗?

    2 回复  |  直到 13 年前
        1
  •  4
  •   Hans Passant    14 年前

    同意。如果 全部的 你的线程需要获得一个可升级的读锁 您无法释放读锁并获取写锁,那么readerwriterlockslim与简单的独占锁相比没有任何改进。递归并不能改变这一点。rwl和避免死锁的危险的需要都非常倾向于一个单线程编写的模式。

        2
  •  1
  •   Brandi    14 年前

    我没有你所有的答案,但我会试一试:

    c中的lock语句是调用monitor.enter和monitor.exit的语法糖。结果是一次只有一个线程可以访问锁中的代码。

    lock()
    {
      //only one thread can access this code at a time
    }
    

    这样做的问题是,多次读取是无害的,但是lock()仍然会阻塞。readerwriterlockslim允许多次读取,只允许一次写入。这是为了提高效率。

    递归策略是必须指定的-默认情况下它是关闭的。不知道更多,但希望这能有帮助。