为了同步对我的属性的访问，我使用 ReaderWriterLockSlim类(class)。我使用以下代码以线程安全的方式访问我的属性。

public class SomeClass
{
    public readonly ReaderWriterLockSlim SyncObj = new ReaderWriterLockSlim();  
    public string AProperty
    {
        get
        {
            if (SyncObj.IsReadLockHeld)
                return ComplexGetterMethod();
            SyncObj.EnterReadLock();
            try
            {
                return ComplexGetterMethod();
            }
            finally
            {
                SyncObj.ExitReadLock();
            }
        }
        set
        {
            if (SyncObj.IsWriteLockHeld)
                ComplexSetterMethod(value);
            else
            {
                SyncObj.EnterWriteLock();
                ComplexSetterMethod(value);
                SyncObj.ExitWriteLock();
            }
        }
    }

    // more properties here ...

    private string ComplexGetterMethod()
    {
        // This method is not thread-safe and reads
        // multiple values, calculates stuff, ect. 
    }

    private void ComplexSetterMethod(string newValue)    
    {
        // This method is not thread-safe and reads
        // and writes multiple values.
    }
}

// =====================================

public static SomeClass AClass = new SomeClass();
public void SomeMultiThreadFunction()
{
    ...
    // access with locking from within the setter
    AClass.AProperty = "new value";
    ...
    // locking from outside of the class to increase performance
    AClass.SyncObj.EnterWriteLock();
    AClass.AProperty = "new value 2";
    AClass.AnotherProperty = "...";
    ...
    AClass.SyncObj.ExitWriteLock();
    ...
}

为了避免每当我获取或设置多个属性时不必要的锁定，一旦我发布了 ReaderWriterLockSlim-Object 并在每次我将要获取或设置一堆时从类外部锁定它特性。为此，我的 getter 和 setter 方法使用 ReaderWriterLockSlim 的 IsReadLockHeld 属性和 IsWriteLockHeld 属性检查是否已获取锁。这工作正常并且提高了我的代码的性能。

到目前为止一切顺利，但是当我重新阅读有关 IsReadLockHeld 和 IsWriteLockHeld 的文档时，我注意到了 Microsoft 的评论:

This property is intended for use in asserts or for other debugging purposes. Do not use it to control the flow of program execution.

我的问题是:为什么我不应该为此目的使用 IsReadLockHeld/IsWriteLockHeld？我的代码有什么问题吗？一切都按预期工作，并且比使用递归锁 (LockRecursionPolicy.SupportsRecursion) 快得多。

澄清一下:这是一个最小的例子。我不想知道锁本身是否必要，或者是否可以删除或以不同的方式实现。我只想知道为什么我不应该使用 IsReadLockHeld/IsWriteLockHeld 来控制文档中所述的程序流。

最佳答案

经过进一步研究后，我在 German Support Forum of the Microsoft Developer Network 上发布了同样的问题并与非常有帮助的主持人 Marcel Roma 进行了讨论。他能够联系到 ReaderWriterLockSlim Joe Duffy 的程序员，他写了这个答案:

I'm afraid my answer may leave something to be desired.

The property works fine and as documented. The guidance really is just because conditional acquisition and release of locks tends to be buggy and error-prone in practice, particularly with exceptions thrown into the mix.

It's typically a good idea to structure your code so that you either use recursive acquires, or you don't, (and of course the latter is always easier to reason about); using properties like IsReadLockHeld lands you somewhere in the middle.

I was one of the primary designers of RWLS and I have to admit it has way too many bells and whistles. I don't necessarily regret adding IsReadLockHeld -- as it can come in handy for debugging and assertions -- however as soon as we added it, Pandora's box was opened, and we RWLS was instantly opened up to this kind of usage.

I'm not surprised that people want to use it as shown in the StackOverflow thread, and I'm sure there are some legitimate scenarios where it works better than the alternatives. I merely advise erring on the side of not using it.

总结一下:您可以使用 IsReadLockHeld 和 IsWriteLockHeld 属性有条件地获取锁，一切都会正常，但是这是一种糟糕的编程风格，应该避免使用它。最好坚持递归或非递归锁。为了保持良好的编码风格，IsReadLockHeld 和 IsWriteLockHeld 应该仅用于调试目的。

我想再次感谢 Marcel Roma 和 Joe Duffy 的宝贵帮助。

关于c# - 微软对ReaderWriterLockSlim.IsReadLockHeld/IsWriteLockHeld的评论及其后果，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/17047122/