ReaderWriterLockSlim: getting a read lock after updating a lock does not throw a LockRecursionException

Question

Regarding ReaderWriterLockSlim :

The acquisition of two locks subsequently in the same stream should actually generate a LockRecursionException (the value of the recursion policy is set to NoRecursion ).

My observation results:

• reader lock, then reader lock → LockRecursionException
• reader lock, then updated reader lock - LockRecursionException
• lock read, then lock write → LockRecursionException
• updateable reader lock, then reader lock → exception
• updatable reader lock and then updatable reader lock → LockRecursionException
• updateable reader lock, then write lock → exception
• write lock, then reader lock → LockRecursionException
• writer lock, then updated reader lock - LockRecursionException
• writer lock, then write lock → LockRecursionException

Is this behavior right?

Answer 1

From the docs :

A thread in upgrade mode can go into read mode by first calling the EnterReadLock method and then calling the ExitUpgradeableReadLock method. This downgrade pattern is allowed for all lock recursion policies, even NoRecursion .

My understanding is that to record a situation, entering a write lock is the normal way to switch from update mode to recording mode anyway, so it needs to be supported even under the NoRecursion policy (it would seem that it makes little sense to update without an update :)