Is there any circumstance in which calling EnterWriteLock on a ReaderWriterLockSlim should enter a Read lock instead?

Question

I have a seemingly very simple case where I'm using System.Threading.ReaderWriterLockSlim in the 3.5 version of the .NET Framework. I first declare one, as shown here:

I put a break point right before the lock is acquired and took a screen shot so you can see (in the watch window) that there are currently no locks held:

Then, after calling EnterWriteLock, as you can see I am holding a Read Lock.

This seems like truly unexpected behavior and I can't find it documented anywhere. Does anyone else know why this happens? In other places in my code (earlier), this exact same line of code correctly obtains a write lock. Consistently, however, across multiple systems it instead obtains a read lock at this place in the call stack. Hope I've made this clear and thanks for taking the time to look at this.

--- EDIT---

For those mentioning asserts... this just confuses me further:

I really can't say how it got past this assertion except that perhaps the Watch Window and the Immediate window are wrong (perhaps the value is stored thread locally, as another poster mentioned). This seems like an obvious case for a volatile variable and a Happens Before relationship to be established. Either way, several lines later there is code that asserts for a write lock and does not have one. I have set a break point on the only line of code in the entire program that releases this lock, and it doesn't get called after the acquisition shown here so that must mean it was never actually acquired... right?

Answer 1

Can you reproduce this in a short but complete program at all?

If you add extra debugging lines, do they get printed and debugged appropriately? I wonder if your built code is out of date with your source...

Answer 2

This could be a debugger side-effect. The ReaderWriterLockSlim class is very sensitive to the current thread ID (Thread.ManagedThreadId). I can't state for a fact that the debugger will always use the current active thread to evaluate the watch expressions. It usually does, but there might be different behavior, say, if you entered the debugger with a hard break.

Trust what the code does first of all, your Debug.Assert proves the point.