【问题标题】：When or why should I use a Mutex over an RwLock?何时或为什么应该在 RwLock 上使用互斥锁？
【发布时间】：2018-11-15 04:30:31
【问题描述】：

当我阅读Mutex 和RwLock 的文档时，我看到的区别如下：

如果你这么说，RwLock 似乎总是比Mutex 更好（更少限制），那我为什么要使用它呢？

【问题讨论】：

【解决方案1】：

有时在 Rust 中使用 Mutex 比使用 RwLock 更好：

`RwLock<T>` 需要更多边界才能使 `T` 成为线程安全的：

换句话说，Mutex 是唯一可以使T 可同步的包装器。我在 reddit 找到了good and intuitive explanation：

由于这些限制，RwLock 要求其内容为 Sync，即两个线程同时拥有该类型的 &ptr 是安全的。互斥锁只需要发送数据，因为从概念上讲，您可以将其想象为当您锁定互斥锁时，它会将数据发送到您的线程，而当您解锁它时，数据会发送到另一个线程。

当您的T 仅为Send 而不是Sync 时，请使用Mutex。

防止作家饿死

RwLock 没有指定的实现，因为它使用系统的实现。有的读写锁会受到writer starvation的影响，而Mutex不会有这种问题。

Mutex 应该在读者可能太多而无法让写者拥有锁时使用。

【讨论】：

只有读者/写者锁的幼稚实现才会让写者挨饿。如果我负责的应用程序将受益于读/写锁，并且如果我必须将它部署在“标准”读/写锁很糟糕的某个平台上，那么我会编写自己的——量身定制我的应用程序的需求——而不是回退到一个简单的互斥体。
我会在这里谈谈performance和intent。那就是 (1) RW Lock 实现通常更复杂，因此更慢；(2) 如果您的算法只需要 Mutex，使用 RW Lock 只会让您的读者感到困惑，没有任何好处。甚至可以增加正确性：如果您只是通过随机将 Mutex 升级到 RW Lock 来解决锁定问题，那么您就完蛋了。多线程和分布式编程需要清晰的数据流模型；只是随机扔锁并不能神奇地纠正流动。
虽然问题是在'rust'标签下，但我发现Java中ReadWriteLock接口的文档对用户必须考虑的各种事情进行了相当全面的讨论在互斥锁和读写锁之间进行选择，以及可能的实现权衡。
@DmitryTimofeev 感谢您的链接！我一定要花时间来完善这个答案。

【解决方案2】：

Mutex 是一种简单的锁定方法，用于控制对共享资源的访问。

读写锁比互斥锁更复杂。

让我自己总结一下：

【讨论】：