Respuesta.

Con el desarrollo de la programación multihilo surgió el problema del acceso simultáneo de varios hilos a los mismos datos. Esto llevaba a errores impredecibles y corrupción del estado del programa.

En Visual Basic .NET se utiliza un mecanismo de bloqueo exclusivo mediante la construcción SyncLock, para garantizar que solo un hilo ejecute cierto código al mismo tiempo.

La solución es usar SyncLock (o Monitor.Enter/Exit) alrededor del código que accede a recursos compartidos, para bloquear el objeto durante la ejecución de la sección crítica.

Ejemplo de código:

Private Shared Counter As Integer = 0
Private Shared ReadOnly CounterLock As New Object()

Public Shared Sub IncrementCounter()
    SyncLock CounterLock
        Counter += 1
    End SyncLock
End Sub

Características clave:

Solo un hilo puede estar dentro de SyncLock para un objeto.
SyncLock requiere un objeto de referencia como token de bloqueo.
Garantiza el desbloqueo incluso si se lanza una excepción.

Preguntas trampa.

¿Se puede usar un valor tipo Integer, String o Nothing como token de bloqueo?

No, SyncLock requiere un objeto de referencia. No se recomiendan las cadenas, ya que pueden ser interning, lo que causaría intersecciones de bloqueo implícitas.

¿Qué sucede si diferentes hilos utilizan diferentes objetos para bloquear una variable?

No habrá sincronización, y se producirá una competencia de hilos: se debe bloquear estrictamente el mismo objeto.

¿Es necesario liberar manualmente el bloqueo después de salir del bloque SyncLock?

No, el desbloqueo ocurre automáticamente al salir del bloque, incluso si hay excepciones.

Errores comunes y anti-patrones

Usar objetos ValueType o String para SyncLock.
No asignar un objeto de "bloqueo" separado, usando Me o objetos existentes.
Bloquear una parte demasiado grande del código, causando caídas en el rendimiento.

Ejemplo de la vida real

Caso negativo

En el código se utilizan cadenas para SyncLock, y varias partes del programa utilizan literales de cadena idénticos. Como resultado, diferentes bloqueos se cruzan y aparecen bloqueos mutuos inesperados (deadlocks).

Ventajas:

Muy fácil de implementar.

Desventajas:

Mayor probabilidad de bloqueos mutuos y congelaciones difíciles de detectar.

Caso positivo

Para cada sección crítica se declara un objeto ReadOnly separado. Solo se bloquea la parte mínima del código que realmente se necesita.