在编写一些线程代码时,我一直在使用 ReaderWriterLockSlim
类来处理对变量的同步访问。这样做时,我注意到我总是在编写 try-finally block ,每个方法和属性都相同。
看到有机会避免重复自己并封装此行为,我构建了一个类 ReaderWriterLockSection
,旨在用作锁的薄包装器,可与 C# 一起使用
block 语法。
类主要如下:
public enum ReaderWriterLockType
{
Read,
UpgradeableRead,
Write
}
public class ReaderWriterLockSection : IDisposeable
{
public ReaderWriterLockSection(
ReaderWriterLockSlim lock,
ReaderWriterLockType lockType)
{
// Enter lock.
}
public void UpgradeToWriteLock()
{
// Check lock can be upgraded.
// Enter write lock.
}
public void Dispose()
{
// Exit lock.
}
}
我使用的部分如下:
private ReaderWriterLockSlim _lock = new ReaderWriterLockSlim();
public void Foo()
{
using(new ReaderWriterLockSection(_lock, ReaderWriterLockType.Read)
{
// Do some reads.
}
}
对我来说,这似乎是个好主意,它使我的代码更易于阅读并且看起来更健壮,因为我永远不会忘记释放锁。
有人能看出这种方法有问题吗?有什么理由说这是个坏主意吗?
最佳答案
嗯,我觉得还可以。 Eric Lippert 之前曾写过关于在“非资源”场景中使用 Dispose
的危险,但我认为这可以算作一种资源。
这可能会使升级场景变得棘手,但此时您总是可以退回到更手动的代码。
另一种选择是编写一个锁获取/使用/释放方法,并提供在作为委托(delegate)持有锁时要采取的操作。
关于c# - ReaderWriterLockSection : A bad idea?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/1900231/