ReaderWriterLockSlim 与 Monitor
我有一个 IDictionary 实现，它在内部保存其他 n 个 Dictionary 并通过键的 HashCode 将该插入分配给各个子字典。 拥有 16 个子词典，在 4 核机器上，冲突次数相当低。
对于并行插入，我使用 ReaderWriterLockSlim 锁定了 Add 方法，仅锁定单个子词典：
public void Add(TKey key, TValue value)
{
int poolIndex = GetPoolIndex(key);
this.locks[poolIndex].EnterWriteLock();
try
{
this.pools[poolIndex].Add(key, value);
}
finally
{
this.locks[poolIndex].ExitWriteLock();
}
}
当使用四个线程插入项目时，我仅获得了大约 32% 的 cpu 使用率和糟糕的性能。 因此，我用 Monitor（即 lock 关键字）替换了 ReaderWriterLockSlim。 CPU 使用率现在接近 100%，性能提高了一倍多。
我的问题是：为什么CPU使用率增加了？ 碰撞次数不应改变。 是什么让 ReaderWriterLock.EnterWriteLock 等待这么多次？
I have an IDictionary<TKey,TValue> implementation that internally holds n other Dictionary<TKey, TValue> and distributes that insertions by the HashCode of the key to the invidual sub-dictionaries. With 16 sub-dictionaries, the number of collisions is pretty low on a 4-core machine.
For parallel insertions, i locked the Add-method with a ReaderWriterLockSlim, locking only the individual sub-dictionary:
public void Add(TKey key, TValue value)
{
int poolIndex = GetPoolIndex(key);
this.locks[poolIndex].EnterWriteLock();
try
{
this.pools[poolIndex].Add(key, value);
}
finally
{
this.locks[poolIndex].ExitWriteLock();
}
}
When inserting items with four threads, i only got about 32% cpu usage and bad performance. So i replaced the ReaderWriterLockSlim by a Monitor (i.e., the lock keyword).
CPU usage was now at nearly 100% and the performance was more than doubled.
My question is: Why did the CPU usage increase? The number of collisions should not have changed. What makes ReaderWriterLock.EnterWriteLock wait so many times?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
对于只写负载，Monitor 比 ReaderWriterLockSlim 便宜，但是，如果您模拟读+写负载，其中读远大于写，则 ReaderWriterLockSlim 应该胜过 Monitor。
For write-only load the Monitor is cheaper than ReaderWriterLockSlim, however, if you simulate read + write load where read is much greater than write, then ReaderWriterLockSlim should out perform Monitor.
我不是专家，但我的猜测是 RWLS 更适合激烈的争用（例如，数百个线程），而
Monitor更适合那些一次性同步问题。我个人使用
TimerLock类，该类使用Monitor.TryEnter和超时参数。I'm no guru, but my guess is that RWLS is more geared towards heavy contention (e.g., hundreds of threads) whereas
Monitoris more attuned towards those one-off synchronization issues.Personally I use a
TimerLockclass that uses theMonitor.TryEnterwith a timeout parameter.你怎么知道是什么导致了糟糕的表现？ 你不能去猜测，唯一的方法就是进行某种分析。
您如何处理父集合的锁定，或者它是恒定的吗？
也许您需要添加一些调试输出并看看到底发生了什么？
How do you know what caused the bad performance? You can't go guessing it, the only way is to do some kind of profiling.
How do you handle locking for the parent collection or is it constant?
Maybe you need to add some debug output and see what really happens?