RwLock死锁与原语的安全性

Question

在教科书读/写锁中，如果作者使用锁，它会阻塞所有新读取器并等待现有读取器退出。然而，Rust文档表明某些特定于系统的实现可以死锁(而教科书中的实现不能死锁吗？)：

锁的优先级策略取决于底层操作系统的实现，并且这种类型不能保证使用任何特定的策略。特别是，等待获得写入锁的写入器可能阻止或不阻止对读取的并发调用.

(文档)。

好奇的是，是否有更多的细节可以解释实现中的这种差异，或者如何选择所需的安全策略？似乎在没有保证的情况下，死锁几乎是肯定的。

Answer 1

文档说锁的公平性取决于操作系统。如果锁对作者不公平，那么连续的读取器流(即使他们单独解锁和重新锁定)可能会阻止作者获得锁。如果发生这种情况，它不会陷入僵局，它就会挨饿。

如果这是一个问题，您可以考虑使用一个公平的锁，如parking-lot的RwLock。

Answer 2

您的教科书是正确的，但是我没有看到文档中有任何部分说明可能会出现死锁。文档说明了这一点，因为线程安全性和并发性是锈蚀的一个重要部分。但是，由于Rust无法保证系统特定的实现超出现有的其他标准。如果即使是单个编译目标可能会阻塞系统特定的实现，那么应该在文档中这样声明，因为否则它可以被视为安全锈蚀中未定义的行为。

但这一点也不值得关注。通过不阻塞，RwLock可以为许多并发读取提供比互斥更好的性能。即使特定于系统的策略有问题，您至少也会得到类型系统提供的保护，强制要求RwLock仅在其内容也是Sync的情况下才是Sync。

// This is also the reason why a RwLock has extra requirements on Sync
impl<T: ?Sized + Send> Sync for Mutex<T> {...}
impl<T: ?Sized + Send + Sync> Sync for RwLock<T> {...}