Analyzers for lock primitives that need thread affinity

Is your feature request related to a problem? Please describe.

I have been advocating for vs threading analyzers, which are awesome to enforce proper async semantics and prevent common anti-patterns.

Unfortunately, while fixing the many violations in a service codebase, a subtle regression was introduced inside a lock scope using ReaderWriterLockSlim which was changed from sync-over-async to proper async calling pattern. Needless to say, the code start throwing exceptions when using this lock.

Given ReaderWriterLockSlim relies on thread affinity and the code did not have enough test coverage to detect the regression, the issue went undetected and resulted in a bad outage.

Describe the solution you'd like

Keeping aside that the correct fix is to use an async lock such as AsyncReaderWriterLock I'd love to see a static analyzer rule to detect misuse of async inside lock scopes that rely on thread affinity such as ReaderWriterLockSlim. Ideally such rule would be bundled in VS Threading analyzers, so this type of regression can be avoided in the future, especially when adopting the VS threading analyzers itself, one would hope it helps reducing issues in code, not adding.

Describe alternatives you've considered

I don't see alternatives to prevent such mistakes at compile time.

Additional context

C# lock​ blocks disallow await​ expressions within them for this reason but analyzers could do the same for other thread-affinitized primitives. Some impacted classes:

• Monitor
• ReaderWriterLock(Slim)
• Mutex

cc: @AArnott

Start by reading the linked VS Threading analyzers documentation and reviewing the existing analyzer rules. The issue names Monitor, ReaderWriterLock(Slim), and Mutex as affected primitives, but no files or tests are specified. Done means detecting async misuse inside these thread-affinitized lock scopes with coverage for the described regression.