【问题标题】:Reader writer lock implementation读写器锁实现
【发布时间】:2012-02-21 17:40:21
【问题描述】:

我有一个作业问题,我必须实现读写器锁。请注意,我不是在寻找/要求代码。我希望了解读写锁的行为,这将有助于我最终确定实现细节。

假设获取锁的请求遵循以下顺序:R W R W R W R W.. 为了防止饥饿,我们应该以相同的顺序处理请求吗?如果我选择跳过写请求(从而给予读者更高的偏好),我如何确保写线程不会饿死?

如果给作者更高的偏好,我认为读者线程有可能会饿死。

我认为我目前的计划适用于 RRRRWRRRRWWWRRRRR、WWWWWRRRRWRRRR、RRRRRRRR、WWWWWW、RWRRR、WRWWWW 等序列。

还有其他我没有考虑的情况吗? - 我知道这是一个很难回答的问题,尤其是。因为我没有透露任何细节,也没有列举我考虑的所有场景。请多多包涵!

【问题讨论】:

  • 在理想的世界中,您应该为所有比最长的正在进行的读取更短的传入读取提供服务。您无法预测,但是您可以采用某种动态方法来适应程序的行为。

标签: synchronization locking


【解决方案1】:

“高优先级”只有在没有等待时间限制时才会产生饥饿。

如果任何线程可以等待的时间限制为某个有限值,则该线程不会饿死。

因此,只要您跟踪线程何时进入队列并且以某种方式不让它们等待“太久”,您就可以在一般情况下(或相反)“将读取器优先于写入器”,同时仍然不会导致活锁。

在选择作家之前只为最大数量的读者提供服务可以获得相同的效果,反之亦然。

【讨论】:

    【解决方案2】:

    在读写器系统中饥饿的通常原因是存在“共享”锁,这些锁允许多个读取器锁定同一资源。

    writer    reader1    reader2
    
              LOCK_SH
              obtained
    LOCK_EX     |       
    waiting     |
       :        |        LOCK_SH
       :        |        obtained
       :        |          |
       :      -------      |
       :                   |
    hungry    LOCK_SH      |
       :      obtained     |
       :        |        -------
       :        |
       :        |        LOCK_SH
    starving    |        obtained
       :      -------      |
       :                   |
                          ...
    

    如果只是简单地选择一个或另一个,您可以简单地有两个队列,一个用于读取器,一个用于写入器,并为每个 Y 个写入器(如果有等待)服务 X 个读取器(如果有的话) )。

    【讨论】:

    • 感谢整洁的小图 ikegami。我认为这两个答案都很棒。我随机选择了一个正确的。可惜两个都接受不了。 :)
    猜你喜欢
    • 1970-01-01
    • 2016-06-05
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-08-28
    • 1970-01-01
    • 1970-01-01
    • 2015-10-15
    相关资源
    最近更新 更多