Adr*_*ian 10 c++ multithreading
从C ++ 17（C ++ 14）开始，我们有了std :: shared_（timed_）mutex类。Qt长期以来都有一个类似的类QReadWriteLock。QReadWriteLock的 文档说：
为了确保不会永远阻止写入者，即使有阻塞的写入者正在等待访问，即使当前仅由其他读取者访问，尝试获取锁的读取器也不会成功。同样，如果某个写程序访问了该锁，而另一个写程序进入了该写程序，则该写程序的优先级高于可能也在等待的所有读程序。
因为这当然是一个合理的属性，所以我想知道 std :: shared_mutex和std :: shared_timed_mutex的行为是否类似？
标准中没有规定。
POSIX没有指定 pthread rwlocks 必须如何决定下一个锁请求成功，因此如果有这样的要求，就不可能std::shared_mutex根据标准 pthreads 来实现 C++。
因为这当然是一个合理的财产
这当然是一个合理的财产，但它不是唯一合理的财产。
例如，GLIBC 有一个 pthreads 扩展，允许您从三种 rwlock 策略中进行选择：递归首选读取器、递归首选写入器和非递归首选写入器。据推测，递归首选编写器并不是所有程序的正确选择。
为了确保作者不会永远被读者封锁......
顺便说一句，这并不能确保作家不会被其他作家永远阻止。
直观上完美公平的解决方案是共享读取器首选独占 FIFO 有序写入器，但这对于许多用途来说都是不必要的重量级。
Qt 版本可能非常适合 Qt 的用例，但它只是轻型/高效 - 重型/一般频谱上的一点。
官方 C++ 标准没有指定std::shared_mutex策略。可以在shared_mutex 参考实现部分的原始 N2406 提案（http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2406.html#shared_mutex_imp）中找到解释：
第二个动机是解释 shared_mutex 中缺少读写器优先级策略。这是由于 Alexander Terekhov 提出的算法，该算法让操作系统决定下一个获取锁的线程，而无需关心是否正在寻找唯一锁或共享锁。这导致完全缺乏读者或作者饥饿。这简直是公平的。
与 QReadWriteLock 实现（即write- preferring ）相比：
为确保写入者不会永远被读者阻塞，如果有阻塞的写入者在等待访问，则试图获取锁的读者将不会成功，即使该锁当前仅被其他读者访问。
提案shared_mutex也是如此，以确保如果新读者不断涌入，作者不会永远等待。
此外，如果一个作者访问了锁，而另一个作者进来了，那么该作者将优先于可能也在等待的任何读者。
shared_mutex在这种情况下，proposal 的情况并非如此，读者和作者具有相同的优先级。
但不幸的是，最终的 C++ 标准文档不包含此参考实现。请注意，尽管 GCC 包含std::shared_mutex基于 N2406 参考实现的实现，但在 Linux 上默认情况下不使用它，它使用pthread_rwlock_t来自 POSIX 线程库（由 中的_GLIBCXX_USE_PTHREAD_RWLOCK_T选项控制c++config.h）。pthread_rwlock_t根据系统设置和应用的pthread属性，可以是读优先或写优先。有关详细信息，请参阅相关问题：How to prevent writer starvation in a read write lock in pthreads