Fundamentos de la concurrencia y la integridad de estado

Cuando múltiples hilos manipulan un recurso compartido sin coordinación explícita, se generan condiciones de carrera. La planificación del sistema operativo intercala las instrucciones de forma no determinista, provocando que las lecturas y escrituras se crucen y el estado final diverja del invariante esperado. Para preservar la coherencia, es necesario encapsular las transiciones de estado dentro de secciones críticas que garanticen la atomicidad mediante mecanismos de exclusión mutua.

En la plataforma .NET, el constructo lock (backeado por System.Threading.Monitor) serializa el acceso a un bloque de código. Cualquier hilo que intente entrar mientras el monitor está ocupado queda bloqueado hasta que se libera la sección, asegurando que solo un consumidor modifique el recurso a la vez.

Escenario problemático: Administrador de capacidad concurrente

Considérese un servicio que gestiona la distribución de plazas limitadas. La implementación inicial presenta vulnerabilidades estructurales visibles bajo carga paralela:

public class CapacityManager
{
    private int _remainingSlots = 50;

    public void ProcessRequests()
    {
        while (true)
        {
            if (_remainingSlots > 0)
            {
                Console.WriteLine($"[Thread {Thread.CurrentThread.ManagedThreadId}] Disponibles: {_remainingSlots}");
                _remainingSlots--;
                Console.WriteLine($"[Thread {Thread.CurrentThread.ManagedThreadId}] Asignado. Quedan: {_remainingSlots}");
            }
            else
            {
                Console.WriteLine("Capacidad agotada.");
                break;
            }
        }
    }
}

Al instanciar múltiples consumidores mediante Task.Run, la salida estándar revela rápidamente inconsistencias: el contador desciende por debajo de cero y varios hilos registran la misma asignación. La falta de atomicidad entre la evaluación de la condición y la mutación del valor es evidente.

Limitaciones de la verificación directa

Intentar validar este comportamiento mediante asertos estándar resulta ineficaz. Las pruebas de concurrencia son estocásticas; depender de la planificación del planificador de hilos para reproducir un fallo genera suites frágiles que pasan en la mayoría de las ejecuciones y fallan aleatoriamente. Para transformar el escenario en uno verificable, se requiere descomponer el flujo de ejecución y aislar los puntos de mutación.

Aplicación del Patrón Objeto Humilde

La estrategia consiste en extraer la lógica de negocio de los efectos secundarios y la coordinación concurrente. Se propone dividir el proceso en verificación de disponibilidad y ejecución de la operación:

public class CapacityManagerV1
{
    public int AvailableSlots { get; set; } = 50;
    public bool InjectLatency { get; set; }

    public void ExhaustInventory()
    {
        while (true)
        {
            if (!AttemptReservation())
                break;
        }
    }

    public bool AttemptReservation()
    {
        if (AvailableSlots > 0)
        {
            if (InjectLatency) Thread.Sleep(1500);
            AvailableSlots--;
            return true;
        }
        return false;
    }
}

Esta separación permite controlar el flujo mediante propiedades de inyección, facilitando la creación de escenarios predecibles sin alterar permanentemente la superficie pública de producción.

Diseño de pruebas para forzar condiciones de carrera

Para validar la vulnerabilidad, se configura un entorno donde dos consumidores inician la operación casi simultáneamente, pero uno se detiene artificialmente justo después de validar el estado y antes de decrementar el contador:

var manager = new CapacityManagerV1();
manager.AvailableSlots = 1;
var synchronization = new CountdownEvent(2);
int capturedState = 0;

Task.Run(() =>
{
    manager.InjectLatency = true;
    manager.AttemptReservation();
    capturedState = manager.AvailableSlots;
    synchronization.Signal();
});

Task.Run(() =>
{
    manager.InjectLatency = false;
    manager.AttemptReservation();
    synchronization.Signal();
});

synchronization.Wait();
Assert.Equal(0, capturedState); // Fallo verificado: el valor es -1

El aserto confirma la violación de invariantes. La inyección de latencia controlada transforma un defecto intermitente en un fallo reproducible, permitiendo validar la corrección antes de implementar la solución de sincronización.

Aislamiento definitivo y refactorización limpia

Para evitar que los artefactos de prueba contaminen la API pública, se emplea herencia exclusiva para el contexto de testing. Esto mantiene el código de producción cohesionado y libre de lógica condicional de depuración:

internal class TestableCapacityManager : CapacityManagerV1
{
    internal void ReserveWithDelay(int milliseconds)
    {
        Thread.Sleep(milliseconds);
        AttemptReservation();
    }
}

La estructura base queda reducida a métodos enfocados en una única responsabilidad, listos para ser protegidos por mecanismos de exclusión:

public class CapacityManagerV2
{
    public int AvailableUnits { get; set; } = 50;

    public void DrainResources()
    {
        while (true)
        {
            if (!ExecuteAllocation())
                break;
        }
    }

    public bool ExecuteAllocation()
    {
        if (HasCapacity())
        {
            CommitDecrement();
            return true;
        }
        return false;
    }

    public bool HasCapacity() => AvailableUnits > 0;

    public void CommitDecrement()
    {
        AvailableUnits--;
    }
}

Las pruebas se adaptan sobrescribiendo el comportamiento de latencia mediante la subclase, manteniendo la integridad del aserto original sin modificar la clase base.

Implementación robusta con exclusión mutua

Una vez validado el problema mediante el entorno determinista, se aplica el bloqueo adecuado. Es fundamental realizar la verificación de estado nuevamente dentro de la sección crítica, ya que el valor puede haber sido consumido entre la llamada inicial y la adquisición del monitor:

public class SynchronizedCapacityManager
{
    private readonly object _syncRoot = new();
    public volatile int AvailableUnits { get; set; } = 50;

    public void DrainResources()
    {
        while (true)
        {
            if (!AttemptSafeReservation())
                break;
        }
    }

    public bool AttemptSafeReservation()
    {
        if (!HasCapacity())
            return false;

        lock (_syncRoot)
        {
            if (!HasCapacity())
                return false;

            CommitDecrement();
            return true;
        }
    }

    public bool HasCapacity() => AvailableUnits > 0;

    public void CommitDecrement()
    {
        AvailableUnits--;
    }
}

El modificador volatile evita que el compilador o la arquitectura de la CPU reordenen las instrucciones o almacenen el valor en cachés locales, garantizando visibilidad inmediata entre los consumidores. La prueba determinista diseñada anteriormente pasa exitosamente, confirmando que la condición de carrera ha sido eliminada y el invariante del sistema se preserva bajo carga concurrente.

La deteción de errores de concurrencia mediante unit testing exige un análisis estático riguroso del flujo de datos y la identificación precisa de las ventanas de vulnerabilidad. Las herramientas de depuración tradicionales y los informes de cobertura son insuficientes para este dominio, ya que no capturan las interacciones temporales entre procesos. La aplicación disciplinada del patrón Humble Object permite descomponer sistemas complejos en unidades verificables, separando la lógica de negocio de los mecanismos de coordinación y produciendo arquitecturas predecibles y alineadas con los principios de alta cohesión.