shared_mutex 锁排序

Question

我的印象是，如果获取了太多共享锁，使用 c++17 的std::shared_mutex 实现的多读取器/单写入器模式可能永远不会放弃唯一锁。

在挖掘cppreference 之后，我不确定情况是否如此。具体来说：

单个互斥体上的所有锁定和解锁操作都发生在单个互斥体上 总订单

例如，给定shared_mutex 上的以下操作，我相信unique_lock 可能永远不会获取。假设无限数量的shared_locks，并且这些锁在第一个shared_locks 释放之前获得。

shared_lock
shared_lock
shared_lock

unique_lock

shared_lock
[...]
shared_lock

给出以下特征。

{ shared_lock, shared_lock, shared_lock, shared_lock, ..., shared_lock } // never releases

unique_lock

但是，如果我正确理解 cppreference，一旦 unique_lock 尝试获取，连续的 shared_locks 将阻塞，直到 unique_lock 被释放。给出以下线程特性。

{ shared_lock, shared_lock, shared_lock} // simultaneous

unique_lock

{ shared_lock, ..., shared_lock} // waits, then simultaneous

所以我的问题是，std::shared_mutex 是否在共享锁和唯一锁之间保持排序？防止由于大量shared_locks被获取而从未获取unique_locks的情况。

编辑：

这是一个代码示例，可帮助您理解问题，并为后代着想。在 MSVC 2019 上，shared_mutex 是安全的，并且可以根据需要进行订购。 unique_lock 确实在 shared_locks 的“无限”数量之前得到处理。

现在的问题是，这个平台是否依赖？

#include <chrono>
#include <cstdio>
#include <mutex>
#include <shared_mutex>
#include <thread>
#include <vector>

using namespace std::chrono_literals;

std::shared_mutex smtx;

int main(int, char**) {

    std::vector<std::thread> threads;

    auto read_task = [&]() {
        std::shared_lock l{ smtx };
        printf("read\n");
        std::this_thread::sleep_for(1s);
    };

    auto write_task = [&]() {
        std::unique_lock l{ smtx };
        printf("write\n");
        std::this_thread::sleep_for(1s);
    };

    // Create a few reader tasks.
    threads.emplace_back(read_task);
    threads.emplace_back(read_task);
    threads.emplace_back(read_task);


    // Try to lock a unique_lock before read tasks are done.
    std::this_thread::sleep_for(1ms);
    threads.emplace_back(write_task);

    // Then, enque a gazillion read tasks.
    // Will the unique_lock be locked? [drum roll]

    // Would be while(true), 120 should be enough for demo
    for (size_t i = 0; i < 120; ++i) {
        std::this_thread::sleep_for(1ms);
        threads.emplace_back(read_task);
    }

    for (auto& t : threads) {
        t.join();
    }
}

输出：

read
read
read
write
read
...
read

Answer 1

std shared_mutex 规范没有指定共享锁和唯一锁的优先级。也没有任何 API 可以设置这样的优先级。缺乏优先级规范的最初动机之一是Alexander Terekhov algorithm as explained here 的存在。

次要动机是解释缺乏读写器 shared_mutex 中的优先级策略。这是由于算法 归功于 Alexander Terekhov，它让操作系统决定哪个线程 是下一个获得锁的人，而不关心是否独特的锁或 正在寻找共享锁。这导致完全缺乏阅读器 或作家饥饿。这很公平。

标准规范不需要 Alexander Terekhov 算法。但是，至少我希望这种算法会更受欢迎，因为缺少规范或 API 来让读者优先于编写者，反之亦然。

this SO answer here 中有更多关于 Alexander Terekhov 算法的详细信息和一些演示其行为的代码。