S2551 — Shared resources should not be used for locking

The instance passed to the SyncLock statement should be a dedicated private field.

Why is this an issue?

If the instance representing an exclusively acquired lock is publicly accessible, another thread in another part of the program could accidentally attempt to acquire the same lock. This increases the likelihood of deadlocks.

For example, a string should never be used for locking. When a string is interned by the runtime, it can be shared by multiple threads, breaking the locking mechanism.

Instead, a dedicated private Lock object instance (or object instance, for frameworks before .Net 9) should be used for locking. This minimizes access to the lock instance and therefore prevents accidential lock sharing.

The following objects are considered potentially prone to accidental lock sharing:

• a reference to Me: if the instance is publicly accessible, the lock might be shared
• a Type object: if the type class is publicly accessible, the lock might be shared
• a String literal or instance: if any other part of the program uses the same string, the lock is shared because of interning

How to fix it

Code examples

Noncompliant code example

Public Sub MyLockingMethod()
    SyncLock Me 'Noncompliant
        ' ...
    End SyncLock
End Sub

Compliant solution

Private lockObj As New Object()
Public Sub MyLockingMethod()
    SyncLock lockObj
        ' ...
    End SyncLock
End Sub

Resources

Documentation

• Wikipedia - Thread
• Wikipedia - Locking
• Wikipedia - Deadlock
• Wikipedia - Interning
• Microsoft Learn - String interning by the runtime
• Microsoft Learn - Managed Threading Best Practices
• Microsoft Learn - SyncLock Statement