【问题标题】：Difference in usage and implementation of ManualResetEvent(Slim), Semaphore(Slim) and ReaderWriterLock(Slim)ManualResetEvent(Slim)、Semaphore(Slim)和ReaderWriterLock(Slim)的用法和实现的区别
【发布时间】：2011-07-20 15:59:43
【问题描述】：

.net 4.0 添加了几个与线程相关的新类：ManualResetEventSlim、SemaphoreSlim 和 ReaderWriterLockSlim。

Slim 版本和旧类之间有什么区别，我应该什么时候使用一个而不是另一个？

【问题讨论】：

标签： c# multithreading .net-4.0

【解决方案1】：

ReaderWriterLockSlim 是 ReaderWriterLock 的更好版本，速度更快，并且不会遭受 writer 饥饿

ManualResetEventSlim 和 SemaphoreSlim 是 ManualResetEvent 和 Semaphore 的完全托管版本，它们在回退到内核对象之前会旋转等待一段时间，因此在等待时间很短时比旧版本更快.

【讨论】：

+1：是的，我自己的个人测试表明，RWL 比普通的 lock 慢了 15 倍。较新的 RWLS 对此进行了相当大的改进，但速度仍可能慢 5 倍。当然，每个人的里程会有所不同。
对于写争用是主要问题的通用线程安全来说，它肯定会比监视器（锁）慢。但是对于读取争用繁重的系统，ReaderWriterLockSlim 将在很大程度上胜过 Monitor。不同的锁定原语针对不同的场景
我只是做了一些更准确的测试。看起来 RWL 比 lock 慢约 5 倍，而 RWLS 慢约 2 倍。所以 RWLS 确实改进了很多。是的，读写锁肯定比普通的旧锁有优势:)
请注意，如果等待时间足够长，ManualResetEventSlim 和 SemaphoreSlim 将创建内核对象。
等待时间对于使用slim版本与否非常重要。如果等待时间较长，您应该使用旧（fat）版本。

【解决方案2】：

我制作了一些插图来帮助我可视化同步原语。希望对其他人也有帮助。

SemaphoreSlim

倒计时事件

障碍

ManualResetEventSlim

【讨论】：

【解决方案3】：

直接引用the documentation

“在 .NET Framework 版本 4 中，您可以使用 System.Threading.ManualResetEventSlim 类在预期等待时间非常短且事件不跨越进程边界时获得更好的性能”

【讨论】：

【解决方案4】：

ManualResetEventSlim 和 SemaphoreSlim 是内核版本的轻量级版本，除非调用它们的 WaitHandle 属性，否则不会分配任何内核对象。

这些类型在调用 Wait 时不会直接阻塞，而是在阻塞前短暂旋转以防它收到信号

ManualResetEventSlim构造函数可以带SpinCount自定义阻塞前spns个数

这两种类型都支持取消，您可以将 CancellationToken 传递给 Wait 方法

SemaphoreSlim 公开了 CurrentCount 属性，而 Semaphore 没有

ManualResetEventSlim 有一个 IsSet 属性，而 ManualResetEvent 没有。

【讨论】：